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REMARKS 

Claims 28-32 have been added. Claims 1-32 are now pending in the Application. No 
new matter has been added. Support for the amendment is found in the Specification, Drawings 
and original claims. Entry of the amendment is respectfully requested. Reconsideration is 
respectfully requested. 

The Pending Claims Are Not Anticipated bv the Applied Art 

Claims 1-27 were rejected under 35 U.S.C. § 102(b) as being anticipated by Rolling, et 
al., U.S. Patent No. 6,385,595 ("Rolling"). 

These rejections are respectfully traversed. The present application was filed on May 25, 
2000. Rolling issued on May 7, 2002 which is after Applicants' filing date. Thus the rejection of 
claims 1-27 under 35 U.S.C. § 102(b) as being anticipated by Rolling is not legally proper. 

In addition, the present application is a continuation-in-part of Application Serial No. 
09/193,787 filed November 17, 1998 and claims the benefit of Provisional Application Serial 
No. 60/149,765 filed August 19, 1999. Further, Application Serial No. 09/193,787 is a 
continuation-in-part of Application Serial No. 09/077,337 filed as PCT/US97/21422 on 
November 25 1997 and claims the benefit of Provisional Application Serial Nos. 60/031,956 
filed November 27, 1996; 60/091,887 filed July 7, 1998; 60/095,626 filed August 7, 1998; and 
60/098,907 filed September 2, 1998. Applicants request acknowledgment of their claim for 
domestic priority. 

Rolling is a continuation of Application Serial No. 08/947,629 (now U.S. Patent No. 
5,963,925) which claims the benefit of U.S. Provisional Application Serial No. 60/028,095 filed 
October 9, 1996. 
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Although, Applicant's earliest provisional application (60/031,956 filed November 27, 
1996) was filed later than Rolling's provisional application (60/028,095 filed October 9, 1996), 
portions of Rolling cited in the Action for supporting the rejection of the claims are not present 
in Rolling's provisional application. Thus in addition to not qualifying as a 35 U.S.C. § 102(b) 
prior art, portions of Rolling relied on in the Action also do not qualify as prior art for purposes 
of rejecting the claims under 35 U.S.C. § 102(e). 

For example, the Action cited Column 15, lines 32-41 of Rolling with respect to steps (a) 
and (b) of claim 1. Column 15, lines 32-41 of Rolling is a discussion of a field (320) containing 
a bank identifier (BIN) and other fields shown in Figure 4. Figure 4 of Rolling is directed to a 
Universal Biller File (UBF). However, Figure 4 of Rolling's Provisional Application 60/028,095 
(enclosed herewith in Appendix A) does not show a UBF or any of the fields described in 
Column 15, lines 32-41 of Rolling. Rather Figure 4 of Rolling's provisional application only 
shows a block diagram illustrating a transaction. Further, Applicants have been unable to find a 
corresponding figure or discussion anywhere in Rolling's provisional application which 
corresponds to Column 15, lines 32-41 of Rolling. 

In addition, the Action cited Figure 3 and reference numerals 216 and 300 of Figure 3 
with respect to step (b) of claim 8. However, Figure 3 of Rolling's provisional application does 
not correspond to Figure 3 of Rolling. Further, Applicants have been unable to find a 
corresponding figure anywhere in Rolling's provisional application which includes reference 
numerals 216 and 300. 

In contrast Applicants' earliest Provisional Application No. 60/031,956 filed November 
27, 1996 (enclosed herewith in Appendix B), fully supports Applicants' independent claims. For 
example, claim 1 recites: a) determining through operation of an automated banking machine, 
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data corresponding to an entity with which a customer operating the machine has an account; and 
b) providing through an output device on the automated banking machine at least one output 
uniquely corresponding to the entity with which the customer has the account. 

Support for the subject matter of claim 1 is found in Applicants 1 earliest provisional 
application such as at page 7, lines 1-18. Here Applicants 1 earliest provisional states that: 

The automated banking machine and system is operative to place a user in 
connection with the institution where they have their accounts. . . To operate the 
baking machine a user inputs an address, such as a URL address, through an 
address input device. The HTML document handling portion operates to connect 
the banking machine to the server corresponding to that address. This is 
preferably accomplished by the user having indicia representative of the address 
on a card that is read by the banking machine. . . If the customer causes the 
machine to connect to a server operated by a foreign institution, the HTML 
documents sent from the foreign institution correspond to those normally provided 
by the foreign institution. As a result the customer is familiar with the interface 
produced by these documents and will be able to more readily operate the banking 
machine. " 

Further examples of the subject matter recited in at least Applicants 1 independent claims is shown 
at page 18, line 3 to page 22, line 19 of Applicants* earliest provisional application. 
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Thus at least Applicants* independent claims are fully supported by Applicants' earliest 
provisional application while Rolling's provisional does not support the features relied on in the 
Action to reject the claims. Thus the portions of Rolling relied on in the Action do not qualify as 
prior art and cannot be used as a basis for a rejection of the claims under 35 U.S.C. § 102. 

The Applied References Do Not Disclose or Suggest 
the Features and Relationships Recited in Applicants' Claims 

Anticipation pursuant to 35 U.S.C. § 102 requires that a single prior art reference contain 
all the elements of the claimed invention arranged in the manner recited in the claim. Connell v. 
Sears, Roebuck & Co., 722 F.2d 1542, 1548, 220 USPQ 193, 198 (Fed. Cir. 1983). 

Anticipation under 35 U.S.C. § 102 requires in a single prior art disclosure, each and 
every element of the claimed invention arranged in a manner such that the reference would 
literally infringe the claims at issue if made later in time. Lewmar Marine, Inc. v. Barient, Inc., 
822 F.2d 744, 747, 3 USPQ2d 1766, 1768 (Fed. Cir. 1987). 

Anticipation by inherency requires that the Patent Office establish that persons skilled in 
the art would recognize that the missing element is necessarily present in the reference. To 
establish inherency the Office must prove through citation to prior art that the feature alleged to 
be inherent is "necessarily present' 1 in a cited reference. Inherency may not be established based 
on probabilities or possibilities. It is plainly improper to reject a claim on the basis of 35 U.S.C. 
§102 based merely on the possibility that a particular prior art disclosure could or might be used 
or operated in the manner recited in the claim. In re Robertson, 169 F.3d 743, 49 U.S.P.Q. 2d 
1949 (Fed. Cir. 1999). 

It is respectfully submitted that the Action does not meet these burdens. 
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The Features Recited in Applicants 9 Claims 
Patentablv Distinguish Over Rolling 

In the Action claims 1-27 were rejected under 35 U.S.C. § 102(b) as being anticipated by 
Rolling. These rejections are respectfully traversed. Applicants response to these rejections is 
based on the Office's referenced interpretation of Rolling. Thus, any change in the Office's 
interpretation of Rolling shall constitute a new ground of rejection. 

In addition to traversing these rejection on the basis that portions of Rolling cited in the 
Action do not qualify as prior art, Applicants further traverse these rejections on the grounds that 
the Rolling reference does not contain all the elements of the claimed invention arranged in the 
manner recited in the claims. Thus, the features, relationships, and steps recited in Applicants' 
claims patentably distinguish over the Rolling reference. 

Claim 1 

Claim 1 is an independent method claim. Claim 1 recites that the method comprises: a) 
determining through operation of an automated banking machine, data corresponding to an entity 
with which a customer operating the machine has an account; and b) providing through an output 
device on the automated banking machine at least one output uniquely corresponding to the 
entity with which the customer has the account. 

The Action cites column 15, lines 32-41 and column 34, lines 5-17 of Rolling with 
respect to steps (a) and (b) of claim 1 . Applicants respectfully disagree that these portions or any 
other portions of Rolling disclose or suggest these steps. For example, column 15, lines 32-41 of 
Rolling states: 
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Field 320 contains a bank identifier number (BIN) that identifies the toiler's bank. 
The BIN may be in any suitable format. By way of example, BIN 322 is a six 
digit number that uniquely identifies the bank used by the biller. Field 324 
contains the biller's bank descriptive data. This descriptive data contains 
information such as bank name, address, telephone numbers, mailing information, 
and other descriptive information. For example, field 324 contains name and 
address information 326 for the Acme Financial Bank. 

Column 34, lines 5-17 of Rolling states: 

CPU 982 is also coupled to an interface 990 that includes one or more 
input/output devices such as such as video monitors, track balls, mice, keyboards, 
microphones, touch sensitive displays, transducer card readers, magnetic or paper 
tape readers, tablets, styluses, voice or handwriting recognizers, biometrics 
readers, or other computers. CPU 982 optionally may be coupled to another 
computer or telecommunications network using a network connection as shown 
generally at 992. With such network connection, it is contemplated that the CPU 
might receive information from the network, or might output information to the 
network in the course of performing the above-described method steps. 

However, neither of these portions of Kolling or any other portion of Kolling suggests all 
of the features, relationships or steps recited in claim 1. For example where do these portions or 
any other portion of Kolling disclose "operation of an automated banking machine"? Nowhere in 
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Rolling is it suggested that the CPU 982 or any other component of Rolling corresponds to an 
automated banking machine. 

As discussed in Applicants' Specification (page 1, lines 7-18), an example of an 
automated banking machine includes an automated teller machine ("ATM"). ATMs enable 
customers to carry out banking transactions including transfers of value. Rolling does not 
disclose or suggest that any portion of the described electronic statement presentment system 
includes the operation of an automated banking machine or ATM. 

Further, Rolling also does not disclose or suggest "determining through operation of an 
automated banking machine, data corresponding to an entity with which a customer operating the 
machine has an account." Column 15, lines 32-41 of Rolling discusses fields or data associated 
with a Universal Biller File (UBF). However, Rolling does not disclose or suggest that such data 
is determined through operation of an automated banking machine. Nor does Rolling disclose or 
suggest such data corresponds to an entity with which a customer operating an automated 
banking machine has an account. Thus Rolling does not disclose or suggest step (a) of claim 1. 

In addition with respect to step (b), where does Rolling disclose or suggest "providing 
through an output device on the automated banking machine at least one output uniquely 
corresponding to the entity with which the customer has the account"? Neither the referenced 
portions of Rolling nor any other portion of Rolling discloses providing such outputs through an 
automated banking machine. 

Rolling does not disclose each and every element, relationship and step of the claimed 
invention arranged in the manner recited in the claims, as is required to sustain the objection. 
Hence, Applicants' claim 1 patentably distinguishes over the Rolling reference. Therefore, it is 
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respectfully submitted that the 35 U.S.C. § 102(b) rejection has been overcome. It follows that 
claims 2-7 which depend from claim 1 are likewise allowable. 

Claim 8 

Claim 8 is an independent method claim. Claim 8 recites that the method comprises: a) 
reading card indicia on a card presented by a customer to an automated banking machine, the 
card indicia including entity data corresponding to an entity with which the customer has an 
account; b) resolving network address data with the banking machine responsive to the entity 
data and data stored in a data store; and c) operating a browser in the banking machine 
responsive to the resolved network address data, to access at least one network address in a 
network, wherein the network address accessed corresponds to an address of a server adapted to 
deliver documents corresponding to the entity with which the customer has the account. 

With respect to step (b) the Action cites Figure 3 and reference numerals 216 and 300. 
Figure 3 of Rolling corresponds to an electronic statement presentment (ESP) System. 
Reference number 216 of Kolling corresponds to a template library. Reference number 300 of 
Kolling corresponds to the previously described universal biller file (UBF). 

However, neither Figure 3, reference numerals 216 and 300, nor any other portion of 
Kolling discloses or suggests an automated banking machine. In addition, Kolling does not 
disclose or suggest as recited in step (b) resolving network address data with an automated 
banking machine responsive to entity data and data stored in a data store. Further Kolling does 
not disclose or suggest that the entity data used to resolve the network address with an automated 
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banking machine was read from a card presented by a customer to the automated banking 
machine. 

In addition, with respect to step (c), Kolling does not disclose or suggest operating a 
browser in an automated banking machine. Further Kolling does not disclose or suggest 
operating the browser responsive to network address data resolved by the automated banking 
machine responsive to entity data read from a card presented by a customer to the automated 
banking machine. Further Kolling does not disclose or suggest operating a browser in an 
automated banking machine to access at least one network address which corresponds to an 
address of a server adapted to deliver documents corresponding to the entity with which the 
customer has the account. 

Kolling does not disclose each and every element, relationship and step of the claimed 
invention arranged in the manner recited in the claims as is required to sustain the objection. 
Hence, Applicants' claim 8 patentably distinguishes over the Kolling reference. Therefore, it is 
respectfully submitted that the 35 U.S.C. § 102(b) rejection has been overcome. It follows that 
claims 9-18 which depend from claim 8 are likewise allowable. 

Claim 19 

Claim 19 is an independent apparatus claim. As discussed previously, Kolling does not 
disclose or suggest an automated banking machine. Further, Kolling does not disclose or suggest 
an automated banking machine which includes a computer having a browser operating therein. 
In addition Kolling does not disclose or suggest an automated banking machine that is operative 
responsive to reading card indicia on a card read by the card reading device of the machine to 
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cause the browser to connect through a network to a network address of an institution server 
corresponding to the card indicia. 

Kolling does not disclose each and every element, relationship and step of the claimed 
invention arranged in the manner recited in the claims, as is required to sustain the objection. 
Hence, Applicants' claim 19 patentably distinguishes over the Kolling reference. Therefore, it is 
respectfully submitted that the 35 U.S.C § 102(b) rejection has been overcome. It follows that 
claims 20-27 which depend from claim 19 are likewise allowable. 

The New Claims 

Claims 28-32 are new dependent claims. Claims 28, 30, and 32 recite that the automated 
banking machine includes a cash dispenser. Claims 29 and 31 depend from claims 28 and 30 
respectively and recite the method further comprises dispensing cash through operation of the 
cash dispenser. Support for these new claims is found in the Specification, Drawings, and 
original claims such as original claims 22 and 26. 

None of the cited references alone or in combination discloses or suggests the features 
and relationships that are specifically recited in the new claim 28-32. In addition, these claims 
recite features, relationships and steps recited in the original claims and are allowable for at least 
the same reasons. As nothing in the cited art discloses nor suggests the features and relationships 
that are specifically recited in the new claims, and because there is no teaching, suggestion or 
motivation cited for combining features of the applied art so as to produce Applicants' invention, 
it is respectfully submitted that the new claims are allowable for these reasons. 
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Additional Comments 

Applicants submitted a second Information Disclosure Statement for the above referenced 
application on September 18, 2001. A copy of this Information Disclosure Statement is attached 
along with Form PTO/SB08 (substitute for Form 1449). Also attached is a copy of the Express 
Mail receipt for the Statement which was stamped as RECEIVED PTO MAIL CENTER on 
September 20, 2001. Applicants respectfully request that receipt of the Information Disclosure 
Statement be acknowledged. 

Additional Claim Fees 
Please charge the fees associated with prosecution of five additional total claims ($90) 
and any other fee due to Deposit Account No. 09-0428 of InterBold. 

Conclusion 

Each of Applicants' pending claims specifically recites features, relationships and steps 
that are neither disclosed nor suggested in any of the applied art. Furthermore, the applied art is 
devoid of any such teaching, suggestion or motivation for combining features of the applied art 
so as to produce Applicants' invention. Allowance of all of Applicants' pending claims is 
therefore respectfully requested. 

The undersigned will be happy to discuss any aspect of the Application by telephone at 
the Examiner's convenience. 
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Respectfully submitted, 




Ralph E 



Reg. No. 31,029 



23 1 South Broadway 
Medina, Ohio 44256 
(330)722-5143 



23 



APPENDIX A 

(U.S. Provisional Application Serial No. 60/028,095 filed October 9, 1996) 



24 



V) 

a 

o 

■O 

to 



CO 
CO 

O 





SERIAL NUM&e« 

- t;,0 / 0 20 : , J?S ;j 

PROv ?. 3 1 uNAi 



FILING DATE 



CLASS 



SUBCLASS 



GROUP ART UNIT 



I g i-yu /;(!■-,, i-.,;;:- 

i ' <E i^iNAKE^Fi/i -n ? lAii. Al>:;A ; Y 



N. ;A; rM. ^ Ms. i;. 



3 

Q. 



ON VI NU I 



■;:i-it--i Li'-iRH : , ChNAL'H „ 



r.' ir- j. ft I -J / p f : r A p r • | j ! j i- : ' I' l O jv ^ 
VERIFIED 



FOREIGN F I L I MGi LICENhF h ran ; ;:;.-> ; . 



Foreign priority claimed □ yes p no 
35 USC 119 conditions met □ yes □ no 

Verified and Acknowledged 



MFCKER A !■ •!(■•, \ AAi 



AS 

FILED 


STATE OR 
COUNTRY 


SHEETS 
DRWGS. 


TOTAL 
CLAIMS 


INDEP. 
CLAIMS 




f: A 









FILING FEE 
RECEIVED 



ATTORNEY'S 
DOCKET NO. 



a 



9UUF7 



EL. EC TRON I C STATEMENT' PRESENT AT T AN 




U.S. DEPT. OF COMM./ RAT. & TM — PTO-436L (Rev. 12-94) 



mm 

pi 



Form PTO-1625 
(Rev. 5/95 



(FACE) 




PATENT APPLICATION 



APPROVED FOR LICENSE 
INITIALS 



60028095 



Received 



•/"•Vf-.Ci'i;, 



CONTENTS-,; • , tei&M&SVL 



_ 12. 
_ 13. 
_ 14. 

-15. 
_ 16. 
_ 17. 
_ 18. 
_ 19. 
_ 20. . 
-21. . 
_ 22. . 
-23. . 
.24. . 
. 25. _ 
. 26. _ 

27. _ 

28. _ 



- 29. 
. 30. 
.31. . 
32. . 



, --yV/ ^^^^^ 




(FRONT) 



POSITION 


ID NO. 


DATE 


CLASSIFIER 






A- ' '. - •■ • 


EXAMINER 






1 


TYPIST 




""9^a — 


/ ' 

ill •-> Irt ' 


VERIFIER 




/ *n/ ) 


7/i? 


CORPS CORR. 






7/ / — 


SPEC. HAND 








FILE MAINT 








DRAFTING 









(LEFT INSIDE) 



PATENT APPLICATION SERIAL NO. 



U.S. DEPARTMENT OF COMMERCE 
PATENT AND TRADEMARK OFFICE 
FEE RECORD SHEET 



V 



PTO-1556 
(5/87) 



66500 U.s p To 

llHf^ >FORPATENT< COVER SHEET 

This is l^lM/t^L filing a PROVISIONAL APPLICATION > FOR PATENT < under 37 CFR 1.53 (b)(2). 



PTO/SB/1S •*>(O2~9<0< 
Apprvrrd rbr um Ihroofii ** > 01/3 1/78 <. OMB 0651-0037 
Patent and Trademark Offlcr, U-3. DEPABTMEffT OF COMMERCI 



Dock** Nmnb«r 



95000 i _£S2- 



Type a plus sign (+ ) 
inaidc thin box-> 



INVHWTOR(«yAPPUCANT(i) 



LAST NAME 


FIRST NAME 


MIDDLE >NAME/< INITIAL 


RESIDENCE (CITY AND EITHER STATE OR FOREIGN COUNTRY] 


Koliing 
Occhino 
Roughgarde 
Hayward 


Ray 

Michael 
n Jeffrey 
James 




San Mateo , • Calif ornia "~ ^" 8 
Castro-Ji^lXey , Calif ornia <■ ^' 1 
"Redwood City, California Oi- 1 
"SHawniqan Lake, Canada c/rf- 



n 



TITLE OF THE INVENTION (MO cfe*ml«i dmi) 



S^i^tr^nxc 



ita±iorx„ 



CORRESPONDENCE ADDRESS > (Indudiag coantrj If not United Stain) < 



<£pIECKER & HARRIMAN 

.,nj 2029 Century Park East 

pi Suite 1600 

y Los Angeles, California 90067 



KN CLOSED APPLICATION PARTS (ck** all thai appty) 



ik 



SpcclOcxtloa Number of Pager 
Drawing) Number of Sheen 



189 



25 



□ 



Small Exility Statement 
[XX I Oiixu- (ipcdfr) 



Return postcard 



METHOD OF PAYMENT (check one) 



XX A check or money order ii enclosed to cover the Provisional Glint feea 



XX 



Tb* Comxniakmer U hereby authorised to charge 
Oline Tees mad credit Deposit Account iSambcn 



08-1520 



PROVISIONAL 
FILING FEJE 
AMOUNT (S) 



$150. 0C 



The invention made by an agency of the United State* Government or under a contract with an agency of the United States Government. 



Mtd Um OrrcraaisnC conLr*cl nunb«t- vt: 




Dat* 



Rejpect fully aubmJttc 
SIGNATURE 
TYPED or T. 

| [ . Additional inventors arc being. named on separately numbered sheets attached hereto 



10 / 9 /96 



REGISTRATION NO. 
Qf appropriate) 



31,023 



> USE ONLY FOR FILING A < PROVISIONAL APPLICATION ** >FOR PATENT < 

Burden HourStaiemenl: This form is estimated tp Irdco 2 houriio complete. Time will vary depending upon iho needs of ihe Individual caie. Any comments on 
the amount of lime you are required to compleio this form should be icnliolhe >Chicnn/ormatlon Offlcor<, Patent uidTradcmarJc Office, Nvoahlnjton, DC 
20231, "DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Assistant Commissioner for Pntents, Wuhlngton, DC 2023 1. 



A 



95000.952 



PROVISIONAL 
UNITED STATES PATENT APPLICATION 



ELECTRONIC STATEMENT 

PRESENTATION 



J RayKolling 
Michael Occhino 
James Hayward 
Jeffrey Roughgaxden 



PREPARED BY: 

HECKER & HARRIMAN 
2029 Century Park East 

Suite 1600 
Los Angeles, CA 90067 

(310) 286-0377 



CERTIFICATE OF MAtUNG 
This is to certify that this correspondence is being 
deposited with the United States Postal Service as Express 

MailLabelNo. Em^QQ^^^^ in 

an envelope addressed to; Commissioner of Patents and 
Trademarks, Washington, D.C. 20231 on: 



FOR 



m 



INVENTORS: 



Oc1nh£r q j 




BACKGROUND OF THE INVENTION 



1. FIELD OF THE INVENTION 



5 The present invention relates to the field of electronic billing and paying 

systems. More particularly, the present invention relates to an electronic 
statement delivery system. 
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01 2. BACKGROUND ART 
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Every month, millions of customers receive bills and other monthly 
statements from utilities, banks, stores, credit card companies, insurance 
companies, and other service providers. Almost all of these bills are sent by 
mail. A typical bill includes four primary components: 

1. Summary information. Typically includes an amount due, a due 
date, a customer account number, a biller name and address. The summary 
information is often printed on a detachable remittance stub that is intended to 
be returned by the customer with a check for payment. 

2. A pre-addressed return envelope. 



3. Detailed invoice of charges. Typically includes a detailed listing of 
the charges accrued. For example, if the bill is a telephone company bill, the 
25 detailed invoice will list details of each toll call. The detailed information may 
include legally mandated information, particularly if the biller is a public utility. 
For example, an electric company may be required to list monthly or yearly 



comparisons of a customer's energy use. The content and format of such legally 
mandated information may vary from one legal jurisdiction (town, county, state) 
to another. 

4. Marketing materials. Billers typically include information such as 
newsletters announcing new products or services, and often also include third 
party advertising pieces. 

A customer typically pays a bill by writing a check for the amount due, 
placing the check and the remittance stub in the return envelope, sealing and 
stamping the envelope, and placing it in the mail. 

For every bill received and paid by a customer, a billing institution (biller) 
has to perform numerous paper handling tasks. First the biller has to generate 
the bill and mail it to the customer. The bill generation process involves 
retrieving billing data for a customer, formatting the billing data in the legally 
prescribed manner, printing each customer's bill, placing the bill and other 
included materials in an envelope, and mailing the envelope to the customer. 
The biller also has to process the payment remittance received. Remittance 
processing involves opening envelopes, identifying the customer's account, 
extracting the check, and presenting the check for payment. Given the large 
volume of bills sent out and payments received each month, the paper handling 
involved is a large and expensive undertaking. 

Various systems have been proposed to reduce the paper handling 
involved in bill paying and remittance processing. For example, there exist 
electronic bill payment service bureaus that allow customers to electronically 
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pay their bills via a home computer or telephone. Although use of these bureaus 
make bill paying more convenient for customers, they make remittance 
processing more expensive for billers. When using a bill payment service, a 
customer directs the service bureau to make payments to the biller. The 
payment origination is usually done electronically. As a result, the remittance is 
not presented to the biller in the usual way, i.e. a check with the biller's 
remittance stub in a single envelope. Instead the biller usually receives a check 
printed.by the service bureau drawn on the customer's bank account. Instead of 
being accompanied by a remittance stub, the customer's account number with 
the biller is printed on the check. Because this form of remittance is different 
from the usual remittance received by the biller, the biller must rjrocess it in a 
special manner, incurring additional expenses. 

ILS. Patent No. 5,465,206, issued November 7, 1995, for "Electronic Bill 
Pay System", assigned to the assignee of the present invention and incorporated 
herein by reference, discloses a bill pay system that allows customers to pay bills 
to participating billers through a centralized payment network operating 
according to preset rules. Thg participating customers receive bills from 
participating billers which indicate an amount owed and a unique biller 
identification number, which is assigned by the payment network. The bills 
may be mailed bills, e-mail notices, or implied bills for automatic debts. To 
authorize a remittance, a customer transmits to its bank, which is a participating 
bank, a bill pay order indicating a payment date, a payment amount, the 
customer's account number with the biller, a source of funds, and the biller's 
biller identification number. The customer's bank then submits a payment 
message to a payment network. The payment network forwards the payment 
message to the biller's bank. For settlement, the customer's bank debits the 
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customer's account and is obligated to a net position with the payment network. 
Likewise, the biller's bank receives a net position from the payment network and 
credits the biller's bank account. The customer initiates bill pay orders manually 
via paper correspondence, at an ATM, via PC, or via telephone keypad. 

5 

Prior art systems have primarily addressed the bill payment portion of 
customer bill processing. The bill generation and presentation portion of 
customer bill processing has not yet been satisfactorily addressed. U.S. Patent 
No. 5,465,206 suggests that bills may be sent electronically by e-mail, but does 
10 not elaborate. U.S. Patent No. 5,007,084 for "Payment Authorization and 
Information Device", issued April 9, 1991, describes a home terminal for 
O receiving and printing out billing information. The billing data is simple text 
m data received by the customer via an encoded signal broadcast by a centralized 
j-i invoice distribution center during vertical blanking intervals of a television 
p 15 broadcast or via telephone lines and a modem. A special device is used to 

decode and print out a hard copy of the received text. The same device can be 
used to pay the bill electronically. 

The electronic bills delivered by these systems consist of simple text 
20 messages. As such, the electronic bills cannot deliver the same variety of 

information and materials as, and are therefore a poor substitute for, traditional 
mailed paper bills. 
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SUMMARY OF THE INVENTION 



The present invention consists of an electronic invoice presentation (EIP) 
system that can be used in conjuction with an electronic bill pay system to 
5 provide a comprehensive electronic bill generation, presentation, and payment 
^ system. Participants include consumers, consumer financial institutions or 
m service providers (CSI/SP), a transport network, biller banks, and billers. 

: ^ Components of the system include a Universal Biller File (UBF), a set of control 

0 ^ ■ 

01 and maintenance transactions, and an invoice delivery system. The UBF is a 

Cj 

□ 10 control file containing key information about all billers participating in the EIP 

Qgj service. The UBF is used to identify billers, to communicate biller service 

Q 

^ options, to perform process edits on data transported between a CSI/SP and a 

biller, and to support CFI/SP service packaging The control and maintenance 
q transactions include service requests, biller requests/confirmations, and CFI/SP 

15 notification. These transactions ensure that the EIP service performs with 
jO certainty and flexibility. The invoice delivery system supports a variety of 

invoice types and delivery options, including delivery of summary invoices to a 
consumer by a certified CFI/SP (a certified CFI/SP is a CFI/SP that meets 
certain minimum security requirements), delivery, of full detail invoices 
20 supporting biller defined graphics and colors by a certified CFI/SP, and invoice 
notification by an uncertified CFI/SP with delivery of summary or full detail 
invoices by a central secure facility. The present invention provides a secure 
electronic invoice presentation system that is flexible enough to accomodate 
almost any biller and any bill or invoice format, and allows convenient and 
25 secure delivery to consumers. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Figure 1 is a schematic diagram illustrating the topology of one 
embodiment of the electronic invoice delivery system of the present invention. 

5 

Figure 2 is a block diagram illustrating the process for adding a biller to 
the universal biller file for one embodiment of the present invention. 

Figure 3 is a schematic diagram illustrating the data flow in a customer 
10 request transaction for one embodiment of the present invention. 

Figure 4 is a block diagram illustrating a customer request transaction for 
one embodiment of the present invention. 

15 Figure 5 is a block diagram illustrating a customer activation request 

transaction for one embodiment of the present invention. 

Figure 6 illustrates Type I invoice presentation in one embodiment of the 
present invention. 

20 

Figure 7 is an illustration of a Type I invoice of one embodiment of the 
present invention. 

Figure 8 illustrates Type II invoice presentation in one embodiment of the 
25 present invention. 
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Figure 9 is an illustration of a Type II invoice of one embodiment of the 
present invention. 

Figure 10 illustrates Type III invoice presentation in one embodiment of 
5 the present invention. 

yij Figure 11 is a block diagram illustrating a customer change in type of 

^ invoice request transaction for one embodiment of the present invention. 

■m 

o 

p 10 Figure 12 is a block diagram illustrating a customer change personal 

m 

^ information request transaction for one embodiment of the present invention. 

s 

m 

^ Figure 13 is a block diagram illustrating a customer request for 

g deactivation of service for one embodiment of the present invention. 

O 15 

^ Figure 14 is a block diagram illustrating a request for changing the 

invoice destination node for one embodiment of the present invention. 

Figure 15 is a block diagram illustrating a customer change paper invoice 
20 delivery option request transaction for one embodiment of the present invention. 

Figure 16 is a block diagram illustrating a customer request for Type I or 
Type II replacement invoice transaction for one embodiment of the present 
invention. 

25 

Figure 17 is a block diagram illustrating a customer request for Type III 
replacement invoice transaction for one embodiment of the present invention. 
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Figure 18 is a block diagram illustrating a customer request for a paper 
copy of an invoice transaction for one embodiment of the present invention. 



5 Figure 19 is a block diagram illustrating a biller confirmation of a 

customer service request transaction for one embodiment of the present 
invention. 

Figure 20 is a block diagram illustrating a biller notification of change in 
10 UBF option transaction for one embodiment of the present invention. 

Figure 21 is a block diagram illustrating a biller deactivation of customer 
account transaction for one embodiment of the present invention. 

15 Figure 22 is a block diagram illustrating a CFI/SP invoice undeliverable 

notification to biller transaction for one embodiment of the present invention. 

Figure 23 is a block diagram illustrating a CFI/SP notification of invoice 
non-delivery transaction for Type I and Type II invoice delivery for one 
20 embodiment of the present invention. 

Figure 24 is a block diagram illustrating a system manager notification of 
invoice non-delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. 

25 
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Figure 25 is a block diagram illustrating a CFI/SP positive confirmation of 
invoice delivery transaction for Type I and Type II invoice delivery for one 
embodiment of the present invention. 

Figure 26 is a block diagram illustrating a system manager positive 
confirmation of invoice delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. 

Figure 27 is a schematic diagram of an example computer system that can 
be used for a customer, biller, bank, or system manager computer system of the 
present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 



In the following description, numerous specific details are set forth in 
order to provide a thorough understanding of the present invention. It will be 
apparent to one skilled in the art, however, that the present invention may be 
practiced without these specific details. In other instances, well-known features 
have not been described in detail in order not to unnecessarily obscure the 
present invention. 

Figure 1 shows the topology of one embodiment of the electronic invoice 
presentation (EIP) system of the present invention. As shown in Figure 1, this 
embodiment includes a biller 100, a biller bank 110, a transport network 120, a 
customer bank 130, a customer 140, and a system manager 150, Biller 100 may 
be any of a variety of entities that provide products or services to customer 140. 
Examples of entities that may be a biller 100 include utility companies, mortgage 
banks, credit card companies, etc. Biller bank 110 is a bank that provides EIP 
services to biller 100. Biller bank 110 may also provide electronic bill payment 
services to biller 100. Transport network 120 is a secure data communications 
network, such as for example the VisaNet(TM), that is used to pass messages 
between biller bank 110 and customer bank 130. Transport network 120 may 
also provide additional system functions, including message verification and 
database maintenance. Customer bank 130 is a bank or other service provider 
that provides EIP services to customer 140. Customer bank 130 is also referred 
to herein as a CFI/SP (Consumer Financial Institution or Service Provider). 
CFI/SP 130 may also provide electronic bill payment services to customer 140. 
Customer 140 is any entity that is a customer of biller 100. System manager 150 
performs a variety of system management operations to insure proper operation 
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of an EIP system. System manager 150 may, for example, be an entity that owns 
transport network 120 and that provides access to biller banks and CFI/SP to an 
EIP system. In one embodiment of the invention, the system manager is Visa 
International. 

Also included in the embodiment of Figure 1 is a Universal Biller File 
(UBF) 160. UBF 160 is a control file containing key information about all billers 
participating in the electronic invoice presentation system of Figure 1. UBF 160 
contains information about billers provided to system manager 150 by the 
billers. UBF 160 is used to identify billers, to communicate biller service options, 
to perform process edits on data transported between a CSI/SP and a biller, and 
to support CFI/SP service packaging. UBF 160 is maintained by system 
manager 150. Updated copies of UBF 160 are periodically distributed by system 
manager 150 to the CH/SP's including CFI/SP 130. 

The particular information contained in a UBF varies according to the 
specific embodiment of the invention, but in general includes all the biller 
information needed by CH/SP's and the system manager for proper operation of 
an EIP system. For example, in one embodiment of the present invention, the 
UBF includes the following entries for each biller: 

Biller name. 

Biller address(es). 

Biller unique identification number (UID). 

Biller account number format. 

Biller invoice formats. 

EIP service options supported by biller. 
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The biller name and biller address entries contain the biller's name and 
address as supplied by the biller. The biller unique identification number is a 
number assigned by the system manager. The biller account number format is 
supplied by the biller and indicates the format used by the biller for customer 
account numbers. The biller invoice format entry is supplied by the biller and 
specifies the format for the electronic invoices of the biller. This entry may, for 
example, include an invoice template containing data fields for monthly invoice 
data, as well as static material that is included with each invoice. The EIP 
service options supported by biller entry is supplied by the biller and indicates 
which EIP service options the biller supports. 

In one embodiment of the invention, EIP service options include: 
Invoice type option. 
Paper invoice delivery option. 
On-demand paper invoice delivery option. 
Personal information change option. 
Positive confirmation of invoice delivery option. 

In one embodiment of the invention, there are three invoice type options, 
designated "Type I", "Type II", and "Type III", respectively. 

The Type I invoice delivery option supports limited data summary 
invoices only, and does not support any graphics or display instuctions. Type I 
is suited for initial biller implementations and invoice delivery for screen phone, 
touch tone and self-service invoice delivery devices. In this option, the biller is 
allowed to send a predetermined number of pre-defined data elements via the 
biller's bank and the transport network to a certified CFI/SP. In one 
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embodiment, this predetermined number is 23. A certified CFI/SP is a CFI/SP 
that has met the system manager's security and other criteria, including 
processing, audit, and liability requirements, for handling sensitive customer 
billing information. In Type I invoice delivery the biller sends the invoice data 
to the biller bank. The biller bank forwards it via the transport network and the 
system manager to the certified CFI/SP. The CH/SP holds the data until 
presented to the customer. When presented to the customer, the CFI/SP formats 
the data for display, using the invoice format for the biller specified in the UBF . 
and the current dynamic customer data received from the biller. 

Figure 6 illustrates Type I invoice presentation in one embodiment of the 
present invention. As shown in Figure 6, in this embodiment, biller 100 sends 
biller bank 110 invoice data for the invoice being presented. Biller bank 110 
sends the invoice data via transport network 120 to system manager 150. System 
manager 150 checks to make sure the invoice data is properly formatted, and 
sends the invoice data via transport network 120 to certified CFI/SP 600. 
Certified CFI/SP 600 formats the data for display on the customer's delivery 
device and presents the data as a limited summary without graphics to customer 
140. 

Figure 7 is an illustration of a summary bill of one embodiment of the 
present invention as may be displayed on a customer's delivery device. The 
summary bill data includes the toiler's name 705, the customer's account number 
715, the customer's name and address 725, a listing of current and previous 
charges 735, an explanation of current charges 745, and a return address 755. 
The summary information corresponds to the information that is normally 
included on the remittance stub of a mailed, paper bill. 
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Type II invoice delivery supports both summary data invoices and full 
detail invoices and supports biller defined color and graphics. In Type II invoice 
delivery, the biller, or the biller bank, creates an invoice template. The template, 
which may include color graphics, contains fields for customer specific invoice 
data. The template may also include static materials, such as marketing graphics 
and text. The template is stored in the biller invoice format entry of the UBF. 
The biller sends dynamic current invoice data for a customer to the biller bank. 
This invoice data is the data for the customer that is specific to the current bill. 
For example, for an electric utility bill, the current invoice data may include the 
dates of usage covered by the bill, the usage amount, the amount of the last 
payment, the current amount due, etc The biller bank sends the current invoice 
data via the transport network and system manager to the customer's certified 
CFI/SP. The CFI/SP assembles an invoice by retrieving the biller's invoice 
template from the CFI/SP's copy of the UBF and merging the received invoice 
data. The CFI/SP holds the invoice until it is delivered to the customer. 

Whether or not the details and graphics included in a Type II invoice are 
actually viewed by a customer depends on the type of delivery device used by 
the customer to access the invoice. If the customer uses a "conforming" device, 
the customer will receive the full bill details. An example of a conforming 
device is a personal computer with a color monitor. If the customer uses a "non- 
conforming" device, however, the customer will only obtain summary invoice 
data. An example of a non-conforming device is a touch-tone phone. 

Figure 8 illustrates Type II invoice presentation in one embodiment of the 
present invention. In this embodiment, as shown in Figure 8, biller 100 sends 
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invoice data to biller bank 1 10. Biller bank formats the invoice data in the 
manner required by transport network 120 and sends the invoice data via 
transport network 120 to system manager 150. System manager 150 checks the 
invoice data for proper format, and sends the invoice data via transport network 
5 120 to certified CFI/SP 600. Certified CFI/SP 600 assembles an invoice by 
retrieving the biller's invoice template from CFI/SP's 600 copy of UBF 160 and 
merging the received invoice data into the appropriate fields of the invoice 
template. CFI/SP 600 holds the invoice until it is delivered to the customer 140. 
The invoice may be delivered to the customer either in the form of summary 
10 data or as detailed data with full graphics depending on the delivery device 
used by customer 140 and the customer's indicated bill type preference. If a 
biller supports Type II invoice presentation, the customer may request delivery 
of either a summary or detailed bill in its sen-ice activation request. 

15 Figure 9 is an illustration of a detailed bill of one embodiment of the 

present invention as may be displayed on a conforming delivery device. Like 
summary invoice 700 of Figure 7, detailed invoice 900 of Figure 9 includes the 
biller's name 705, the customer's account number 715, the customer's name and 
address 725, a listing of current and previous charges 735, an explanation of 
current charges 745, and a return address 755. In addition, detailed invoice 900 
includes additional details and graphics, including a logo 950, a graph showing 
a comparison of present and previous monthly electricity use 910, a energy 
conservation message 920, and advertisements 930 and 940. Detailed invoice 900 
in general may contain such detail as allows a biller to completely replace the 
25 biller's mailed paper bill with electronic detailed invoice 900. 



20 
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Detailed invoice 900 contains items from the biller's invoice template, 
dynamic current invoice data, and static invoice data. Items from the biller's 
invoice template include the biller's name 705, return address 755, and logo 950. 
In addition, the locations for the remaining items are specified by the invoice 
template. Of the remaining items, customer account number 715, customer 
name and address 725, current and previous charges 735, explanation of current 
charges 745, and detailed history of energy use 910 constitute dynamic current 
invoice data for the customer. Energy conservation message 920 and 
advertisements 930 and 940 may each constitute static invoice data or dynamic 
current invoice data, depending on whether an item is included in all customer 
invoices (in which case the item constitutes static invoice data) or whether an 
item is specifically selected for the customer, for example based on the 
customer's demographics (in which case the item constitutes dynamic current 
invoice data). Static invoice data is changed by the biller by updating the biller's 
invoice template in the UBF. 

Type III invoice presentation is applicable when the customer's CFI/SP is 
a non-certified CFI/SP. Because the customer's CFI/SP is not certified, it is not 
authorized to handle the customer's confidential billing information. Instead, 
the invoice is held by the system manager. The customer receives a message 
from the customer's non-certified CH/SP indicating that a bill has arrived. The 
customer then contacts the system manager directly to obtain a copy of the bill. 
Type III invoice presentation supports detailed and summary invoices. 

Figure 10 illustrates Type III invoice presentation in one embodiment of 
the present invention. In this embodiment, as shown in Figure 10, biller 100 
sends invoice data to biller bank 110. Biller bank 110 sends the invoice data via 
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transport network 120 to system manager 150. System manager 150 checks the 
invoice data for proper format If the format is proper, system manager 150 
retrieves the biller's invoice template from the system manager's copy of UBF 160 
and assembles an invoice using the biller's invoice template and the invoice data 
received from biller bank 110. System manager 150 sends a notice of the waiting 
invoice via transport network 120 to non-certified CFI/SP 1000. Non-certified 
CFI/SP 1000 passes on the notice of the waiting invoice to customer 140. To 
receive the invoice, customer 140 sends a request, for example via a dial-up 
modem connection, to system manager 150. System manager 150 validates the 
customer's identity, for example using a password and/or PIN number system. 
Once the customer's identity has been validated, system manager 150 conveys 
the invoice to customer 140. System manager 150 may use the same dial-up 
connection used by customer 140 to transmit the invoice to customer 140, or the 
invoice may be presented to the customer on another display device. 

If a biller supports Type III invoice delivery, the customer may request 
either detailed or summary invoices, , 

V 

One embodiment of the present invention includes the following paper 
bill delivery options that a biller may specify in the UBF: 
Biller always mails paper invoice. 
Biller never mails paper invoice. 

Biller will activate paper invoice delivery on customer's request. 
Biller will cease paper invoice delivery on customer's request 
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One embodiment of the present invention requires the biller to deliver 
paper invoices together with electronic invoices, regardless of paper bill delivery 
option chosen, for the first three month's of EIP service.- 

One embodiment of the present invention includes two on-demand paper 
bill delivery options that a biller may specify in the UBF: 
Biller supports option. 
Biller does not support option. 
If the biller supports the on-demand paper bill delivery option, the biller agrees 
to send a complete paper invoice to a customer upon demand. 

s 

One embodiment of the present invention includes two personal 
information change options that a biller may specify in the UBF: 

Biller allows electronic change of a customer's personal information. 
• Biller does not allow electronic change of a customer's personal 
information. 

One embodiment of the present invention includes three confirmation of 
invoice delivery options that a biller may specify in the UBF: 
20 Biller supports option for all customers. 

Biller supports option for specified customers only. 
Biller does not support option. 
If the biller supports a confirmation of invoice delivery for a customer, the 
CFI/SP is required to confirm to the biller each invoice delivery to a customer. 

25 

Figure 2 is a block diagram of the process used to add a new biller to the 
UBF in one embodiment of the present invention. As shown in Figure 2, the 
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process begins when the biller fills out a biller questionnaire at block 200. The 
biller files the questionnaire with the biller bank at block 210, and the biller bank 
conveys the biller data contained in the biller questionnaire to the system 
manager at block 220. The system manager adds the new biller data to the UBF 
at block 230, and distributes the updated UBF to the CFI/SP's at block 240. The 
distribution at block 240 may occur at regular intervals, or whenever the system 
manager believes the amount of changes made to the UBF warrants distribution 
of an updated version of the UBF. 

In addition to the UBF, other components of the electronic invoice 
presentation (EIP) system of the present invention include a set of control and 
maintenance transactions, and an invoice delivery system. 

The set of control and maintenance trancsactions allows CFI/SP's and 
billers to control and maintain the EIP service. The transactions occur according 
to a set of pre-defined rules. These rules ensure that the EIP service performs 
with certainty and flexibility. The transactions control such functions as service 
activation, service deactivation, and maintenance of the service structure. 

Figures 3 and 4 illustrate a customer service request transaction of one 
embodiment of the present invention. A customer service request includes any 
request from a customer related to the EIP system. Examples of customer service 
requests in one embodiment of the invention include: 

A customer activation request 

A customer request for a change in type of invoice. 

A request to change a customer's personal information. 

A customer request to deactivate service. 
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A request to change the invoice destination node. 

A customer request to change a paper invoice delivery option. 

A customer request for a replacement invoice. 

A customer request for a paper copy of an invoice. 

As shown in Figures 3 and 4, a customer service request transaction 
originates when a customer 140 conveys a request for service to CFI/SP 130. 
This step is indicated by the number 1 in Figure 3 and as block 400 in Figure 4. 
CFI/SP 130 formats the request in the manner required by transport network 120 
and transmits it via transport network 120 to system manager 150. This step is 
indicated by numbers 2 and 3 in Figure 3 and block 410 in Figure 4. As shown 
in Figure 4, after receiving the request, system manager 150 checks to see if the 
request is proper at block 430. A proper request is one that is properly 
formatted, that comes from a participant CFI/SP, that relates to a participant 
biller, and that requests a type of service that the biller provides. . 

If the request is not a proper request, system manger 150 sends CFI/SP 
130 an error message at block 440. 

If the request is proper, system manager 150 sends the request to biller 
bank 110 via transport network 120 at block 450. This step is also indicated by 
numbers 4 and 5 in Figure 3. Biller bank 110 in turn conveys the request to biller 
100. This step is indicated by number 6 in Figure 3 and block 460 in Figure 4. * 

The method steps shown in 4 apply generally to any customer service 
request transaction. For specific types of transactions, the method steps may 
include transaction-specific details. 
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Figure 5 is a block diagram illustrating a customer activation request 
transaction for one embodiment of the present invention. As shown in Figure 5, 
a customer initiates activation of an electronic invoice presentation service from 
5 a specified biller by sending the customer's CFI/SP a request for activation of 
EIP service at block 500. The request specifies the biller with whom the 
Jj customer wishes to activate service, the customer's account number with the 
H biller, and the invoice delivery option the customer wishes to receive. After the 

; ^ customer's CFI/SP receives the customer's request for EIP service activation, the 

Ji 10 CFI/SP formats the request for transmission via the secure transport network to 

the system manager. In one embodiment, the format used is the "VIP SMS" 
^ format. In another embodiment, the format used is the "BASE II TC50" format. 

•a 

W In one embodiment, the information contained in the request for service 

M= activation transmitted to the system manager by the CFI/SP includes: 

□ 

Q 15 • Invoice type. 

Jj Invoice destination node. 

Paper invoice option. 

Delivery method (Type II or III only) 

PIN/password (Type III only) 
20 Device type. 

The invoice type indicates which type of invoice delivery will be used. In 
this embodiment, the invoice types are Type I, Type II, and Type III as described 
with respect to Figures 6-10. The invoice type selected must be an invoice type' 
25 supported by the applicable biller. 
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The invoice destination node is the node that will hold the invoice for 
presentation to the customer. For Types I and II, the invoice destination node is 
the cusomer's certified CFI/SP. For Type III, the invoice destination node is the 
system manager* 

5 

The paper invoice option indicates which paper invoice delivery option 
the customer desires. The paper invoice option selected must be an option that 
is supported by the biller. 

10 The delivery method indicates whether the customer wishes to receive 

Jj summary invoice data, a detailed invoice, or both. This information is only 

^ needed if the invoice type is Type II or Type III. For Type I there is no choice, 

only summary invoice data is available. 

§** 

□ 15 The PIN/password entry specifies the PIN and or password that the 

=U customer will use to obtain an invoice from the system manager. This entry is 

only used for Type III invoice delivery. 

The device type entry indicates which device type, conforming or non- 
20 conforming, will be used by the customer to display electronic invoices. 

As shown in Figure 5, the CFI/SP formats the service request and sends it 
via the transport network to the system manager at block 510. The system 
manager receives the request and checks it for form and content at block 520. 
25 For example, the system manager checks that the request is formatted in the 
proper format required to transmit it via the transport network, checks to make 
sure the biller specified is a participant in the EIP system, and compares the 
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service options specified in the request to the service options supported by the 
biller as specified in the UBF. 

If the request is found to be improper at block 530, the system manager 
sends the CFI/SP an error message at block 540. An example of an improper 
request is a request for a service option not supported by the applicable biller. 

If the request is found to be proper at block 530, the system manager 
sends the request on to the biller bank, via the transport network, at block 550. 
The biller bank conveys the request to the biller at block 560. The biller updates 
the biller's database to reflect activation of service by the customer, and stores 
the customer's service preferences at block 570. The biller sends a confirmation 
of receipt of the service activation request to the CFI/SP, via the biller bank and 
transport network, at block 580. 

Figure 11 is a block diagram illustrating a customer change in type of 
invoice request transaction for one embodiment of the present invention. This 
type of transaction is available only if the biller supports the new type of invoice 
the customer is requesting. As shown in Figure 11, this type of transaction 
begins when a customer conveys a request for a change in the invoice type 
delivered by a particular biller to the customer's CFI/SP at block 1100. The 
CFI/SP formats, the request (for example as a VIP SMS formatted or BASE II 
TC50 formatted transaction) and sends it via the transport network to the system 
manager at block 1110. The system manager checks the request for proper form 
and content (including biller support of the invoice type requested) at block 
1120. If the system manager finds the request improper at block 1130, the system 
manager sends the CFI/SP an error message at block 1140. If the request is 
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proper, the system manager sends the request via the transport network to the 
biller bank at block 1150. The biller bank conveys the request to the biller at 
block 1160. In one embodiment, the biller bank is required to convey the request 
to the biller within two days of receipt. The biller updates the biller's database 
with the customer's new preference at block 1170, and sends a confirmation via 
the transport network to the CFI/SP at block 1180. 

Figure 12 is a block diagram illustrating a customer change personal 
information request transaction for one embodiment of the present invention. 
This type of transaction is available only if the biller supports the option of 
allowing changes in a customer's personal information by electronic means. As 
shown in Figure 12, this type of transaction begins when a customer conveys a 
request for a change in personal information to the customer's CFI/SP at block 
1200.. The CFI/SP formats the request (for example as a VIP SMS formatted or 
BASE II TC50 formatted transaction) and sends it via the transport network' to 
the system manager at block 1210. The request includes, as applicable, the 
former and present values of the customer billing address, the customer last 
name, and the customer phone number. The system manager checks the request 
for proper form and content, including checking whether the biller supports 
electronic changes in customer personal information, at block 1220. If the system 
manager finds the request improper at block 1230, the system manager sends the 
CFI/SP an error message at block 1240. If the request is proper, the system 
manager sends the request via the transport network to the biller bank at block- 
1250. The biller bank conveys the request to the biller at block 1260. In one 
embodiment, the biller bank is required to convey the request to the biller within 
two days of receipt. The biller updates the biller's database with the customer's 
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new personal information at block 1270, and sends a confirmation via the 
transport network to the CFI/SP at block 1280. 

Figure 13 is a block diagram illustrating a customer request for 
deactivation of service for one embodiment of the present invention. A customer 
may request this type of transaction, for example, if the customer is terminating 
service with a specific biller of with a CFI/SP. As shown in Figure 13, this type 
of transaction begins when a customer conveys a request for deactivation of 
service to the customer's CFI/SP at block 1300. The CFI/SP formats the request 
(for example as a VIP SMS formatted or BASE II TC50 formatted transaction) 
and sends it via the transport network to the system manager at block 1310. The 
system manager checks the request for proper form and content at block 1320. If 
the system manager finds the request improper at block 1330, the system 
manager sends the CFI/SP an error message at block 1340. If the request is 
proper, the system manager sends the request via the transport network to the 
biller bank at block 1350. The biller bank conveys the request to the biller at 
block 1360. In one embodiment, the biller bank is required to convey the request 
to the biller within two days of receipt. The biller deactivates the customer from 
the biller's EIP service at block 1370, and sends a confirmation via the transport 
network to the CFI/SP at block 1380. 

Figure 14 is a block diagram illustrating a request for changing the 
invoice destination node for one embodiment of the present invention. A 
CFI/SP may request this type of transaction, for example, when the CFI/SP 
changes the invoice destination node internally. This may occur, for example, 
when the customer switches from one delivery device (e.g. a touch-tone phone) 
to another delivery device (e.g. a personal computer). As shown in Figure 14, 
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this type of transaction begins when a CFI/SP generates a request for a change of 
destination node, formats the request (for example as a VIP SMS formatted or 
BASE II TC50 formatted transaction) and sends it via the transport network to 
the system manager at block 1410. The system manager checks the request for 
proper form and content at block 1420. If the system manager finds the request 
improper at block 1430, the system manager sends the CFI/SP an error message 
at block 1440. If the request is proper, the system manager sends the request via 
the transport network to the biller bank at block 1450. The biller bank conveys 
the request to the biller at block 1460. In one embodiment, the biller bank is 
required to convey the request to the biller within two days of receipt. The biller 
updates the biller's database to reflect the new invoice destination node at block 
1470, and sends a confirmation via the transport network to the CFI/SP at block 
1480. 

. Figure 15 is a block diagram illustrating a customer change paper invoice 
delivery option request transaction for one embodiment of the present invention. 
This type of transaction is available only if the biller supports the paper invoice 
delivery option to which the customer wishes to change. As shown in Figure 15, 
this type of transaction begins when a customer conveys a request for a change 
in paper invoice delivery option to the customer's CFI/SP at block 1500. The 
CFI/SP formats the request (for example as a VIP SMS formatted or BASE II 
TC50 formatted transaction) and sends it via the transport network to the system 
manager at block 1510. The system manager checks the request for proper form 
and content, including checking whether the biller supports the new paper 
invoice delivery option, at block 1520. If the system manager finds the request 
improper at block 1530, the system manager sends the CFI/SP an error message 
at block 1540. If the request is proper, the system manager sends the request via 
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the transport network to the biller bank at block 1550. The biller bank conveys 
the request to the biller at block 1560. In one embodiment, the biller bank is 
required to convey the request to the biller within two days of receipt. The biller 
updates the biller's database with the customer's new paper invoice delivery 
preference at block 1570, and sends a confirmation via the transport network to 
the CFI/SP at block 1580. 

Figure 16 is a block diagram illustrating a customer request for Type I or 
Type II replacement invoice transaction for one embodiment of the present 
invention. A customer may make such a request, for example, if the customer 
has lost or damaged the original invoice and needs another copy. In one 
embodiment of the present invention, for Type I and Type II invoice delivery, 
the CH/SP is required to store copies of electronic invoices for a specified period 
of time after delivery to the customer. In one embodiment, this period of time is 
one billing cycle. As shown in Figure 16, this type of transaction begins when a 
customer requests a replacement invoice from the customer's CFI/SP at block 
1600. In the request, the customer includes a unique invoice ID that identifies 
the invoice for which the customer wishes to receive a replacement. The CFI/SP 
retrieves the invoice identified by the unique invoice ID and delivers a 
replacement copy to the customer at block 1610. 

Figure 17 is a block diagram illustrating a customer request for Type III 
replacement invoice transaction for one embodiment of the present invention. In 
one embodiment of the present invention, for Type III invoice delivery, the 
system manager stores copies of electronic invoices for a specified period of time 
after delivery to the customer. In one embodiment, this period of time is 
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one billing cycle. As shown in Figure 17, this type of transaction begins when a 
customer requests a replacement invoice from the system manager at block 1700. 
In the request, the customer includes a unique invoice ID that identifies the 
invoice for which the customer wishes to receive a replacement as well as the 
customer's PIN and/or password. The system manager verifies the PIN and/or 
password of the customer, and retrieves the invoice identified by the unique 
invoice ID and delivers a replacement copy to the customer at block 1710. 

Figure 18 is a block diagram illustrating a customer request for a paper 
copy of an invoice transaction for one embodiment of the present invention. 
This type of transaction is available only if supported by the biller. A customer 
may request a paper copy of a bill if the customer needs more detail than 
provided by a summary invoice or if the customer needs an invoice for receipt 
purposes. As shown in Figure 18, this type of transaction begins when a 
customer conveys a request for a paper copy of a specific biller's invoice to the 
customer's CFI/SP at block 1800. The request includes a unique invoice 
identification number. In one embodiment of the-invention, the request must be 
made within two billing cycles of the original invoice date. The CFI/SP formats 
the request (for example as a VIP SMS formatted or BASE II TC50 formatted 
transaction) and sends it via the transport network to the system manager at 
block 1810. The system manager checks the request for proper form and content, 
including checking whether the biller supports paper invoice delivery, at block 
1820. If the system manager finds the request improper at block 1830, the system 
manager sends the CFI/SP an error message at block 1840. If the request is 
proper, the system manager sends the request via the transport network to the 
biller bank at block 1850. The biller bank conveys the request to the biller at 
block 1860, In one embodiment, the biller bank is required to convey the request 
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to the biller within two days of receipt. The biller produces the paper bill and 
sends it to the customer at block 1870, and sends a confirmation via the transport 
network to the CFI/SP at block 1880. In one embodiment of the invention, the 
biller may impose permanent delivery of paper bills, instead of electronic bills, if 
5 a customer frequently requests paper copies of invoices. 

m In one embodiment of the present invention, biller request/confirmation 

Jj control and maintenance transaction types include: 

Q 

ffi Biller confirmation of service request 

□ 1 0 Biller no tif ica tion of change in UBF option. 

Biller deactivation of a customer account 



m 



Figure 19 is a block diagram illustrating a biller confirmation of a 
customer service request transaction for one embodiment of the present 
15 invention. In one embodiment of the present invention, biller confirmation is 
mandatory for the following service requests: 
Customer activation of service. 
Invoice Type change. 

Change in customer personal information. 
20 Customer request for a paper copy of invoice. 

Change in paper invoice delivery option. 
Change of invoice destination node. 
Customer requested deactivation. 

25 As shown in Figure 19, this type of transaction beginswhen a biller receives a 
request for service at block 1900. The biller sends a record to the biller bank 
confirming the information contained in the service request at block 1910. The 
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confirmation includes particulars of the service requested. The biller bank 
formats the confirmation (for example as a BASE II TC50 formatted transaction) 
and sends it via the transport network to the system manager at block 1920. In 
one embodiment of the invention, the biller bank must send the confirmation to 
the system manager within five days of receiving the original service request 
from the system manager. The system manager checks the confirmation for 
proper form and sends the confirmation via the transport network to the 
customer's CFI/SP at block 1930. The customer's CFI/SP conveys the 
confirmation to the customer at block 1940. In one embodiment, the CFI/SP 
need not convey the confirmation to the customer if the service request was for a 
change in invoice destination node or a customer requested deactivation. 

Figure 20 is a block diagram illustrating a biller notification of change in 
UBF option transaction for one embodiment of the present invention. As shown 
in Figure 20, this type of transaction begins when a biller changes one or more 
UBF options at block 2000. The biller generates a change in UBF options notice 
\ for each affected customer and sends the notice to the biller bank at block 2010. 
The notice includes particulars of the UBF option change. The biller bank 
formats the notice (for example as a BASE II TC50 formatted transaction) and 
sends it via the transport network to the system manager at block 2020. In one 
embodiment of the invention, the biller bank must send the notice to the system 
manager within two days of receiving the notice from the biller. The system 
manager checks the notice for proper form and sends the notice via the transport 
network to the customer's CFI/SP at block 2030. The customer's CFI/SP conveys 
the notice to the customer at block 2040. In one embodiment, the CFI/SP must 
convey the notice to the customer within one day after receiving it. 
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Figure 21 is a block diagram illustrating a biller deactivation of customer 
account transaction for one embodiment of the present invention. A biller may 
deactivate a customer's account if the customer terminates its relationship with 
the biller (e.g. the customer pays off a loan), if the biller ceases to provide the 
service the customer was receiving, if the customer abuses electronic invoicing, 
or for some other reason. As shown in Figure 21, this type of transaction begins 
when a biller generates a notice of deactivation of a customer's account at block 
2100. In one embodiment of the present invention, the deactivation notice must 
be sent by the biller to the biller bank within 1 day after a customer termination. 
In one embodiment, the notice must include the reasons for the deactivation. 
The biller bank formats the deactivation notice (for example as a BASE II TC50 
formatted transaction) and sends it via the transport network to the system 
manager at block 2110. In one embodiment of the invention, the biller bank 
must send the deactivation notice to the system manager within two days of 
receiving the notice from the biller. The system manager checks the notice for 
proper form and sends the notice via the transport network to the customer's 
CFI/SP at block 2120. The customer's CFI/SP updates its database to reflect the 
customer deactivation at block 2130, and conveys the deactivation notice to the 
customer at block 2140. In one embodiment, the CFI/SP must convey the notice 
to the customer within one day after receiving it. 

In one embodiment of the present invention, CFI/SP notification control 
and maintenance transaction types include: 

CFI/ SP invoice undeliverable notification to biller. 
CFI/SP invoice non-delivery notification to biller (Types I and II). 
System manager invoice non-delivery notification to biller (Type III). 
CFI/SP positive invoice delivery confirmation to biller (Types I and II). 
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System manager positive invoice delivery confirmation to biller (Type III). 

Figure 22 is a block diagram illustrating a CFI/SP invoice undeliverable 
notification to biller transaction for one embodiment of the present invention. 
Such a notification arises when a CFI/SP receives an invoice that it cannot 
deliver to a customer, because, for example, the customer is not on file with the 
CFI/SP. The biller therefore must be notified that the invoice has been sent to a 
wrong destination. As shown in Figure 22, this type of transaction begins when 
a CFI/SP receives an invoice that it cannot deliver at block 2200. The CFI/SP 
generates an invoice undeliverable notification at block 2210. The notification 
includes the reason why the invoice is undeliverable. The CFI/SP formats the 
notification (for example as a VIP SMS or BASE n TC50 formatted transaction) 
and ( sends it via the transport network to the system manager at block 2220. In 
one embodiment of the invention, the CFI/SP must send the undeliverable 
notification to the system manager within one day after the CFI/SP discovers 
that the invoice is undeliverable. The system manager checks the notification for 
proper form, including insuring that the biller to whom it is addressed is a 
participant in the EIP system, at block 2222. If the notification is not of proper 
form, the system manager sends the CFI/SP an error message at block 2225. If 
the notification is of proper form, the system manager checks if the notification 
relates to a Type III invoice delivery option at block 2230. If the notification 
relates to a Type III invoice delivery option, the system manager deletes the 
undeliverable invoice from its invoice storage at block 2240. The system 
manager sends the notification via the transport network to the biller bank at 
block 2250. The biller bank conveys the undeliverable notification to the biller at 
block 2260. In one embodiment, the biller bank must convey the notification to 
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the biller within two days after receiving it. The biller updates its database with 
the undeliverable status of the invoice at block 2270. 



Figure 23 is a block diagram illustrating a CFI/SP notification of invoice 
5 non-delivery transaction for Type I and Type II invoice delivery for one 

embodiment of the present invention. For Type I and Type II invoice delivery, 
7f £ the customer's certified CFI/SP is responsible for delivery of the invoice to a 

jj customer. A CFI/SP sends a notification of invoice non-delivery to a biller if the 

£ invoice due date has passed without the customer receiving the invoice. The 

10 customer may not have received the invoice because, for example, the customer 
Jjjf did not access the device over which the invoice is delivered to the customer. As 

O shown in Figure 23, this type of transaction begins when an invoice delivery 

Ul date passes without the invoice having been delivered to the customer at block 

k« 2300. The customer's CFI/SP generates an invoice non-delivery notification at 

O 15 block 2310. The CFI/SP formats the notification (for example as a VIP SMS or 
L J BASE II TC50 formatted transaction) and sends it via the transport network to 

. the system manager at block 2320. In one embodiment of the invention, the 
CFI/SP must send the invoice not delivered notification to the system manager 
within one day after the invoice due date. The system manager checks the 
20 notification for proper form, including insuring that the biller to whom it is 

addressed is a participant in the EIP system, at block 2330. If the notification is 
not of proper form, the system manager sends the CFI/SP an error message at 
block 2340. If the notification is of proper form, the system manager sends the 
notification via the transport network to the biller bank at block 2350. The filler 
25 bank conveys the non-delivery notification to the biller at block 2360. In one 

embodiment, the biller bank must convey the notification to the biller within two 
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days after receiving it. The biller updates its database with the invoice non- 
delivery (or bill not read) status at block 2370. 



Figure 24 is a block diagram illustrating a system manager notification of 
invoice non-delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. For Type III invoice delivery, the 
customer's non-certified CFI/SP delivers a notice of waiting invoice to the 
customer, but the system manager is responsible for delivery of the invoice to 
the customer. The system manager sends a notification of invoice non-delivery 
to a biller if the invoice due date has passed without the customer receiving the 
invoice. The customer may not have received the invoice because, for example, 
the customer did not access the device over which the invoice is delivered to the 
customer. As shown in Figure 24, this type of transaction begins when an 
invoice delivery date passes without the invoice having been delivered to the 
customer at block 2400. The system manager generates an invoice non-delivery 
notification at block 2410. The system manager formats the notification (for 
example as a VIP SMS or BASE II TC50 formatted transaction) and sends it via 
the transport network to. the biller bank at block 2420. In one embodiment of the 
invention, the system manager must send the invoice not delivered notification 
to the biller bank within one day after the invoice due date. The biller bank 
conveys the non-delivery notification to the biller at block 2430. In one 
embodiment, the biller bank must convey the notification to the biller within two 
days after receiving it. The biller updates its database with the invoice non- 
delivery (or bill not read) status at block 2440. 

Figure 25 is a block diagram illustrating a CFI/SP positive confirmation of 
invoice delivery transaction for Type I and Type II invoice delivery for one 
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embodiment of the present invention. A biller may request a CFI/SP to provide 
confirmation of delivery to allow the biller to determine when the customer has 
received an invoice. The biller may make a blanket request that a CFI/SP 
provide confirmation of delivery for all invoices by specifying a confirmation of 
5 delivery option in the biller's entry in the UBR Alternatively, if the biller wishes 
confirmation of delivery for a specific invoice only, the biller may include a 
J request for confirmation in the invoice itself when it is sent to the CRI /SP. The 

^ responsible CFI/SP sends a positive confirmation of invoice delivery to a biller 

5j£ when the customer has downloaded the invoice to a delivery device. As shown 

10 in Figure 25, this type of transaction begins when an invoice is delivered to the 
^ customer's delivery device at block 2500. The customer's CFI/SP generates an 
O confirmation of delivery notification at block 2510. The confirmation includes 

yl the date on which the customer received the invoice. The CH/SP formats the 

M= notification (for example as a VIP SMS or BASE II TC50 formatted transaction) 

O 15 and sends it via the transport network to the system manager at block 2520. In 
yi one embodiment of the invention, the CFI/SP must send the notification to the 

system manager within one day after delivery of the invoice to the customer. 
The system manager checks the notification for proper form, including insuring 
that the biller to whom it is addressed is a participant in the EIP system, at block 
20 2530. If the notification is not of proper form, the system manager sends the 
CFI/SP an error message at block 2540. If the notification is of proper form, the 
system manager sends the notification via the transport network to the biller 
bank at block 2550. The biller bank conveys the delivery notification to the biller 
at block 2560. In one embodiment, the biller bank must convey the notification 
25 to the biller within two days after receiving it. The biller updates its database 
with the invoice delivered status at block 2570. 
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Figure 26 is a block diagram illustrating a system manager positive 
confirmation of invoice delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. A biller may request confirmation of 
delivery to allow the biller to determine when the customer has received an 
5 invoice. The biller may make a blanket request for confirmation of delivery for 
all invoices by specifying a confirmation of delivery option in the biller's entry in 
the UBF. Alternatively, if the biller wishes confirmation of delivery for a specific 
invoice only, the biller may include a request for confirmation in the invoice 
itself when it is sent to the system manager. The system manager sends a 
10 positive confirmation of invoice delivery to a biller when the customer has 

downloaded the invoice to a delivery device. As shown in Figure 26, this type of 
transaction begins when an invoice is delivered by the system manager to the 
customer's delivery device at block 2600. The system manager generates a 
confirmation of delivery notification at block 2610. The confirmation includes 
15 the date on which the customer received the invoice. The system manager 
formats the notification (for example as a VIP SMS or BASE H TC50 formatted 
transaction) and sends it via the transport network to the biller bank at block 
2620. In one embodiment, the system manager must send the delivery 
notification to the biller bank within 1 day of delivery of the invoice to the 
20 customer. The biller bank conveys the delivery notification to the biller at block 
2630. In one embodiment, the biller bank must convey the notification to the 
biller within two days after receiving it. The biller updates its database with the 
invoice delivered status at block 2640. 



25 



One embodiment of the present invention is described in Appendix 1. As 
stated in Appendix 1, this embodiment includes a category of participants 
referred to as "statement originators." Statement originators include billers that 
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generate invoices, but also include other entities such as banks and stock brokers 
that provide periodic statements to customers that are not bills for services but 
that provide information to customers (such as bank account balances). Such 
non-biller statement originators may use the invoice delivery capabilties of the 
present invention to deliver electronic versions of their periodic customer 
statements in the same manner as billers use the invoice delivery capabilites of 
the present invention to deliver bills. 

The embodiment described in Appendix 1 also includes options for 
including interactive fields in statements delivered to customers. These 
interactive fields allow the customer to request additional information by 
activating an interactive field. For example, a statement may include an 
interactive field consisting of an advertisement for a product or service provided 
by a third party. Activating this field, for example by positioning a cursor on the 
field and activating a mouse button, causes the retrieval of information about the 
product or service. In one embodiment, activating an interactive field creates a 
link to a web page on the World Wide Web. 

Additional details of this embodiment are described in Appendix 1. 

The present invention can be implemented by m6ans of software 
programming on any of a variety of one or more computer systems as are well 
known in the art, including, without limitation, computer systems such as that 
shown in Figure 27. The computer system of Figure 27 may, for example, be 
used as a customer computer, a biller computer, a bank computer, or a system 
manager computer. The computer system shown in Figure 27 includes a CPU 
unit 2700 that includes a central processor, main memory, peripheral interfaces, 
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input-output devices, power supply, and associated circuitry and devices; a 
display device 2710 which may be a cathode ray tube display, LCD display, gas- 
plasma display, or any other computer display; an input device 2730, which 
may include a keyboard, mouse, digitizer, or other input device. The computer 
system may or may not include non-volatile storage 2720, which may include 
magnetic, optical, or other mass storage devices, and a printer 2750. The 
computer system may also include a network interface 2740, which may consist 
of a modem, allowing the computer system to communicate with other systems 
over a communications network. Any of a variety of other configurations of 
computer systems may also be used. 

Thus a novel system for electronic invoice presentation has been 
presented. Although the present invention has been described with respect to 
certain example embodiments, it will be apparent to those skilled in the art that 
the present invention is not limited to these specific embodiments. . For example, 
although the operation of certain embodiments has been described in detail 
using certain detailed process steps, some of the steps may be omitted or other 
similar steps may be substituted without departing from the scope of the 
invention. Further, although the invention has been described as utilizing the 
VisaNet(TM) as a transport network, other networks or other communications 
media may be used. 
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Introduction 



This document presents the planned system architecture for Visa International^ (Visa's) 
Electronic Statement Presentment System (ESP). ESP will represent a major extension 
of Visa's existing Electronic Payments System (ePay). 

A Phase I Pilot Program for ESP is scheduled to commence in early 1997. 

Figure 11 - Customer and Statement Originator ESP Architecture on page 3 shows the 
major players and the types of data transferred through Visa's ePay System, as extended by 
the ESP project. Principal players (or roles) include: 

• Statement Originators. Organizations that originate statements or bills, e.g., 
a bank issuing statements or a local business issuing monthly bills to its 
customers. 

• Billers. A subset of Statement Originators that originate Statements having an 
amount that is due and payable. 

• Biller Financial Institution. Financial institutions that serve Billers by 
receiving payments on their behalf sent through Visa*s ePay system, and by 
sponsoring Statement Originators into the ESP System. 

• Statement Service Providers (SSP*s). Organizations that receive statement 
data from one or more Statement Originators and cause it to be delivered either 
via Visa's ESP system or otherwise (e.g., U.S. Mail). These may be financial 
institutions or other institutions sponsored by financial institutions, 

• Visa International. The world's largest processor of credit card transactions. 
Visa develops, maintains and promotes the Visa ESP Service. This includes the 
ESP System, operating rules, standards, and related pricing. 

• Customer Financial Institution/Service Providers (CSPs). Organizations 
that receive statement data from multiple Statement Originators via Visa's ESP 
System or otherwise and deliver these statement^ to Customers electronically. 

• Originating Banks. Financial institutions that hold the accounts Customers 
use to pay Statements. 

• Customers. Statement recipients. Examples of Customers include individuals 
like you and me, as well as businesses. 

Some organizations may carry out multiple roles. For example, a financial institution may 
be both Statement Originator and Customer Financial Institution. Very large Statement 
Originators may function as their own Statement Service Provider. A financial institution 
may choose to become both a Statement Originator and a Customer Financial 
Institution I Service Provider. 

Statement Originators must be sponsored into Visa's ESP Service by a Biller Financial 
Institution to participate. This usually entails a contract and payment of fees. 

Visa will access fees for the ESP Service only to Biller Financial Institutions and Customer 
Financial Institutions participating in the service. These organizations determine fee 
structures and rates to Statement Originators and Customers. 

For a description of the differences between the architecture described in 
Versions 1.1 and 1.2 of this document, see Appendix A - What's New ?on page 84. 
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ESP System Architecture 



Overview 



For a description of the differences between the architecture described in 
Versions 1,1 and 1.2 of this document, see Appendix A - What's New ? on page 84. 

A. The System 

1. Components 

As shown in Figure 11 - Customer and Statement Originator ESP Architecture on page 3, 
the full ePay system consists of a Payments "layer", which is used to process electronic 
payments made by Customers to Statement Originators, and a Statement "layer" which is 
used by Statement Originators to present electronic versions of Statements to Customers. 
The flows of data in the Payments layer of the system are shown in dashed lines and are 
marked "Outside of ESP Project's Scope". 

The Payment layer of ePay passes data for Payments from a Customer's PC to an 
Originating Bank which submits the Payment to Visa's Base II computer system. Base II 
settles the transaction and sends it to a Biller Bank Workstation (BBWS) at the Biller's 
Bank who updateB the Biller's account. 

2. Data Flow 

As shown in Figure 22 - A Simplified ESP System Data Flow on page 4, the ESP System 
passes Statement data in the other direction, in three distinct streams. The first two 
streams consists exclusively of character data; the other stream contains both character 
data and binary data associated with graphics (e.g., logos) and other multimedia features 
(e.g., sounds and movie clips). 

The first stream of character data, consists of Statement Content Records, are sent in 
batches of sets, where each set represents one Customer Statement for one billing cycle. It 
is relatively small (1 to 5 KB, degending upon the Statement), but must be transmitted for 
every Statement processed. 

The second stream of character data, consists of Administrative Messages, are sent 
between all parties in the system. 

The third stream, the binary data, consists of Statement Templates, each representing the 
format and layout of a single Statement Type. It is relatively large (30k to 100k, depending 
upon the Statement), but is transmitted only when a change to the Statement format is 
made. 

The Statement Content Records (SLR, SAR, and SCR in Figure 1 - e.g.: amount due, 
transaction details, etc.) begin at the Statement Originator's A/R department and are 
transmitted to the Statement Service Provider's (SSP) System. They are then passed to 
Visa's Statement Originator Side ESP Workstation, where they are processed for transfer 
through Visa's ePay Switch, and on to Visa's ESP Statement Generation Workstation at the 
CSP's site. 

See Appendix G • ESP System Data Flow Projections. 
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3. Rendering the Statement 

As shown in Figure 33 - Generating the Fully-Rendered Statement on page 5, a set of 
Statement Content Records are combined with their Statement Template into Fully 
Rendered Statement PDF Files. These are then passed to the CSP*s Home Banking 
Software front end for delivery to Customers either via private network or the World Wide 
Web. 

B. Performance Objectives 

Key performance objectives for the ESP system include the: 

g • Capability to produce consistent presentation-quality Statements completely 
fpl within the control of the Statement Originator. 

~0 • Capability to produce Statements of arbitrary complexity, including variable 
«f length, multi-section Statements whose content and format could depend on 

O Customer-specific data. 

S[ • Capability to display and print Statements, taking maximal advantage of 
g available hardware, independent of platform and operating system. 

fU • Capability to display interactive Statements with features, including for 
|g example, pay buttons, optional targeted marketing Generic Enclosures, World 

p Wide Web links, the ability to transmit blank forms and receive forms data (e.g., 

y2_ loan applications), as well as the ability to play sound and video clips. 

- 1 • Economic data transmission. This is accomplished by dividing Statements into 
= durable template data and volatile content data, storing the durable data as near 

H to the Customer as feasible, and thereby minimizing transmission of repetitive 

□ data through the system. 



'4J 
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Consumer 
Financial Institution I 
Service Provider 




Statement Content Record Sets 
are received from the ePay 
Switch* and loaded into a 
secure (SQL Server) database. 

Statement Content Record Sets 
are processed into Fully 
Rendered Statement PDF Files 
as follows: 

• A Statement Print Image is 
produced in PDF format by a 
Microsoft Access Report. 

• The Access Report also 
generates a PDF M erge 
Control Table, specifying 
which PDF Files are to be 
merged to make up this 
Customer's Statement. 

• PDF Files are merged, 
under control of the PDF 
Merge Control Table, to 
make up the Fully Rendered 
Statement PDF File. 

PDF Files can be Statement 
Originator-Specific Interactive 
Pages or Generic Enclosures. 



Figure 3 - Generating the Fully-Rendered Statement PDF File 
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C. A Glossary 

1. The Players 



===== , — ^ — 

Statement Originator 


Organizations that originate statements or bills, e.g., a bank 
issuing statements or a local business issuing monthly bills to 
its customers. 


Biller 


A subset of Statement Originators, organizations that 
originate Statements that have an amount due and payable 


Biller Financial Institution 


Financial institutions that serve Bilters by receiving 
payments on their behalf sent through Visa's ePay system. 


Statement Service Provider 


Organizations that receive statement data from one or more 
Statement Originators and cause it to be delivered either via 
Visa's ESP system or otherwise (e.g., U.S. Mail). These may 
be financial institutions or other institution a ln^in^inrv 
Statement Originators* sponsored by financial institutions. 


SSP 


A Statement Service Provider 


Visa International 


The world's largest processor of credit card transactions. 
Visa develops, maintains and promotes the Visa ESP Service. 
This includes the ESP System, operating rules, standards, 
and related pricing. 


Customer Financial 
Institution/Service Provider 


An organization that receives statement data from multiple 
Statement Originators via Visas ESP System or otherwise 
and delivers these statements to Customers electronically. 


CSP 


A Customer Financial Institution /Service Provider. 


Originating Banks 


Financial institutions that hold the accounts Customers use 
to pay Statements. May or may not be a CSP. 


Customer 


Statement recipients. Examples of Customers include 
individuals like you and me, as well as businesses. 

Identified by one or more unique combinations of UBF Biller 
ID and CBAN. 


UBF Biller W 


A unique Visa-assigned number identifying the Statement 
Originator. 12 digits 


SSP Biller ID 


How the SSP knows the Statement Originator. 


SSP ID 


A unique Visa-assigned number identifying the SSP. 
"B" & 5 digits. 


CSPW 


A unique Visa-assigned number identifying the CSP. 
6 digits. 


CBAN 


Qustomer Biller Account Number. How the Statement 
Originator knows the Customer. 


CSP Account Number 


How the CSP knows the Customer. Not required. 
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2. The Statement 



Statement 

■ 


A collection of Documents from a single Statement Originator t 
addressed to a single Customer t for a single Statement Cycle 
Date. Traditionally mailed in a single envelope. 

May or may not include an Amount Due. 

In an electronic statement, one document is mandatory, 
consisting of both Customer-Specific- and Static Documents. 
Other documents are optional and made available at the 
Customer's request. At most, one optional document is 


Document 


A portion of a Statement which may be Static, Data-Bound- 
Fixed-Length or Data-Bound-Variable-Length. An entire 
Document may be included or not included for a given 
Statement. Each Document usually consists of one or more 
pages. 


Static Document 


A document whose contents is the same for all Customers 
receiving a given Statement during a given Statement Cycle 
Date. 


\yi*onfifns/ kjfJw iff Ajovutnen* 


x\ umuiiiHiiL wiiuotJ cu i lud nil is cuiiereiik lur eucn KfUatAjnuir 

receiving a given Statement during a given Statement Cycle 
Date 


Generic Enclosures 


A Static Document one that is the same for ALL copies of 
the Statement, regardless of tho Customers data. 
Traditionally included within a Statements envelope. 
Represented as a PDF file. 


1 Interactive Page 


Adobe Acrobat Forms Objects in a PDF file which can be 
added to a Statement PDF file during creation of the Fully 
Rendered Statement PDF File. 

For an example, see Figure 44 • A Mock-Up of a 
Statement on page 11 ' 


Mandatory Customer-Specific 
Pages 


The main Customer-Specific Document, included on all 
Statements. E.g.: a bill summary. 


Mandatory Generic Enclosure 


A Generic Enclosure included on all Statements. E.g.: 
regulatory notices. 


Optional Customer-Specific 
Pages 


A Customer-Specific Document which may be requested by 
the Customer via the Interactive Page. E.g.: bill details. 


Optional Generic Enclosure 


One of possibly several Generic Enclosures which may 
be requested by the Customer via the Interactive Page. 
E.g.: promotions. 


Fully Rendered Statement PDF 
File 


A Statement ready for viewing by the Customer, in a single 
Adobe PDF (Eortable Uocument £ormat) File. 


Optional Customer-Specific 
PDF File 


A PDF File containing Optional Customer-Specific Pages. 
At most, one per Statement. 


Optional Generic PDF File 


A PDF File containing Optional Generic Enclosures. There 
may be several of these for one Statement. 
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Mini Statement 


A summary of a Statement, typically based on 
Statement Descriptor data, and typically used for 
displaying a Statement on a non-conforming device 
(e.g.: a touch-tone telephone, as opposed to a PC or 
Macintosh). 


Statement Cycle Date 


A Statement reflects business done during a given time 
period^ often one month. 



Statement Descriptor 


A fixed set of data fields, common to ALL Statements. 

The data necessary for the CSP to generate a Mini Statement 
for the Customer and to allow the Customer to pay the 
Statement through the ePay system. This includes all 
necessary control and routing data. 

It is in the form of an ASCII comma-delimited record, and 
includes the filename of the associated Fully Rendered 
Statement PDF File. 

This data is defined on page 42 and depends upon Statement 
Type. 


Statement Types 


Currently, three distinct Statement Types have been defined: 
Invoices, Account Summaries, and Advisory Messages 


Invoices 


The defining characteristic of an Invoice is that it can (but 
need not) contain a demand to be paid a specified amount by 
a specified date. 


Account Summaries 


The defining characteristic of an Account Summary is that it 
reports a summary of activity pertaining to a financial 
account, and does not contain an explicit demand for 
payment. 


Advisory Messages 


An advisory message is essentially a free text message 
delivered electronically. 
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Statement Template 


A Microsoft Access *.MDB file containing the resources 
necessary to generate a Statement from a Statement Content 
Record Set. Contains Statement Stationary and, optionally, 
other binary resources. Relatively large. 


Statement Template Number 


A unique Visa-assigned number identifying the Statement 
Template. T & 7 digits. E.g.: T0040456 


Statement Template Version 
Number 


A Visa-assigned number identifying a version of the 
Statement Template. 4 digits. E.g.: 1056 


statement 1 emplate UJ 


Statement Template Number + V+ Statement Template 
Version Number, E.g.: T0040456vl056 


Template Resource 


Every resource file used by a Template. Pont files, PDF files, 
graphics, etc. 


Template Resource ID 


Statement Template Number + "_"+ Statement Enclosure 
Number. Assigned sequentially by Visa. E.g.: T0040456 0031 


Statement Stationary 


The stable portion of a Statement, in a format analogous to 
printed stationary. Relatively large. 


Statement Content 
\ Transparency 


The volatile portion of a Statement in PDF format. Relatively 
small. 


|| ' Retention Period 


The period of time that Statement Content Data is kept at 
the ESP Statement Generation Workstation. Typically 6 
months. 


Statement Generation 


Creation of one or more Statement PDF file(s) from a 
Statement Content Record Set 


Statement Rendering 


Processing of one or more Statement PDF files and, 
optionally. Statement FDF files for display. 


Standard Statement Rendering 
\ Tool(SSRT) 


Software designed to generate and display a Statement. 
See The Standard Statement Rendering Tool on page 49. 
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3. The Data 



SAR Stream 


Statement Legacy Records, Augmented - "Print Stream" 

OKlK;rriV/U ItAJUIUH tttJUL lrUIH til 6 &t&lBfrlGrlf \Jt Iff lild tOf lAJ 1116 

SSP t for Customers who have requested ESP delivery of this 
Statement, with data added by the SSP to assist with ESP 
processing. 


SAR Record 


A single record from the SAR Stream 


SAR Statement Record Set 


The SAR Stream records pertaining to a single Statement 


SAR Document Record Set 


The SAR Stream records making a single Document 


SAR Stream Type 


These records come in a wide variety of formats; Fixed- 
Jjengthy Delimited, and Print Stream records are three of the 
formats found in use today. SAR data may also be stored by 
the SSP in an SQL database. 


Statement Content Data 


Parsed and fielded SAR data used to generate a Statement. 


Statement Content Record Set 


Statement Content Data for a single Statement. May be in 
comma-delimited ASCII format for transmission, or in a 
Statement Content Table Set. 


Statement Content Table Set 


A set of SQL tables stored in an ODBC-compliant database at 
the CSP. Contains Statement Content Data for: 

• one Statement Template 

• many Customers 

• many Statement Periods (data prior to the Retention 
Period is purged)) 




I Transmission Number (Xmn #) 


This sequential number is assigned to each e-mail 
transmission. It is unique within each transmitter. When 
concatenated behind the transmitter's identification 
("ePaySw", SSP W t or CSP ID), it forms a system-wide 
unique identifier. - , " 

e.g.: tt ePaySw.342045\ "612345.23432" 


Hash Total 


A value calculated from a pre-defined set of data within an e- 
mail message, ASCII file, SQL table, or other data collection. 
This value is typically used to detect changes to the data. 
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The Details 

A. The Statement 

A Statement is presented to a Customer as a Fully Rendered PDF File. The Customer views 
this PDF File via Adobe Reader, either as a Web Browser add-in or as an OLE Object in a 
proprietary home banking system. 



1 . A Sample Statement 




Figure 4 - A Mock-Up of a Statement 

In Figure 44 ■ A Mock-Up of a Statement on page 11, the CSP is "Very 
Friendly Bank" and the SSP is "Brook Furniture Rentals". 




In this example: 




The PDF File consists of three parts: the CSP's Home Banking Software, the 
Interactive Page, and the Statement, 
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a. CSP's Home Banking Software 



In our example, the Home Banking Software is web-based on a 
private Intranet (you can see Microsoft's Internet Explorer in the 
background). The CSP-supplied "Pay It" button is, in this case, an 
HTML button. 

Many Home Banking Software systems are based on proprietary 
software that in normally run without connection to the CSP's 
system. It dials up the CSP only when the Customer requests 
uploads or downloads of data. We refer to this type of system as 
"proprietary, off-line". 




Either type of system can use Adobe's Reader software to display the 
Fully Rendered Statement PDF Files generated by the ESP System. 
(Note that Figure 4 uses Adobe Exchange - in production, Reader 
will be used instead). 



b. The Interactive Page 




This consists of an Adobe PDF Form that has 6 Objects: the ''New 
Warehouse", "Lower Rates", "Office Furniture", and "Edwardian" 
buttons, which are "generic" - common to all Customer's Statements; 
a non-interactive graphical area showing the "Kirsten" message, and 
the "Baby Furniture" button. 

The "Kirsten" message and "Baby Furniture" buttons are generated 
specifically for Ms Public's Statement by the Access Report, and are 
added to the form via an Adobe FDF file. 

i. The Buttons 

Each of the Adobe buttons can have one of a pre-defined set , 
of actions. At this time, the following actions are defined: 

e Download Optional Enclosure x 

• Download Optional Customer-Specific Pages 

During generation of the Customer's Statement, the 
Template generates the FDF File which defines, among other 
things, the actual actions taken when each of the buttons are 
pressed. 
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For example, pressing a "Show Optional Enclosure 4 n button 
on a web-based system may cause a web link to a CSP- 
specific URL, while pressing the same button on a 
proprietary off-line system may cause execution of a program 
which places an order for "Optional Enclosure 4" on the 
download queue for the next connection to the CSP. 

The exact definition of these actions have yet to be 
determined. 



c. The Statement 

« A Statement consists of four parts: Statement Descriptor, Fully 

H Rendered Statement PDF File, Optional Customer-Specific Pages, and 

£ Optional Generic Enclosures. 

H I The Statement Descriptor 

O 

01 This ASCII text contains all data necessary to pay the 

Statement and to display it on Non-Conforming Devices. 



m 



See page 42 for a definition of the Statement Descriptor. 
The Fully Rendered Statement PDF File 



The Interactive Page, Mandatory Customer-Specific Pages & 
Ul Mandatory Generic Enclosures are all included in the Fully 

= Rendered Statement PDF File. 

^ The Mandatory Customer-Specific Pages are generated by 

y the Access Report within the Statement Template for each 

y Customer's Statement 

The Interactive Page and the Mandatory Generic Enclosures 
are separate PDF Files. 

These and, optionally, a Customer-Specific FDF File, are 
merged with the Mandatory Customer-Specific PDF File to 
make the Fully Rendered Statement PDF File. 

111. Optional Customer-Specific Pages 

A second, Optional Customer-Specific PDF File, is generated, 
at the discretion of the Statement Originator, by a second 
Access Report within the Statement Template. 

Iv. Optional Generic Enclosures 

Any number of Optional Generic Enclosures can be defined 
for a Statement. These are in the form of PDF files, which 
are downloaded at the Customer's request. 



2. Performance Considerations 

By keeping the Mandatory Customer-Specific Pages and Mandatory Generic 
Enclosures as small as possible, and by placing as much detail as possible 
into the Optional Customer-Specific Pages, the Statement Originator can 
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greatly decrease the time it takes the Customer to see and pay their 
Statement. 

Statistics on downloads of Optional Customer-Specific Pages and Optional 
Generic Enclosures will be kept and made available to the Statement 
Originator. 



in 



ffj 
CO 
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B. TPL - The Statement Template 

A Statement Template is a Microsoft Access v7.0 Database (an MDB file). Associated binary 
resources are stored within the MDB file. This file can be compressed by PKZip for efficient 
transmission and storage at the ePay Switch. 

In addition, Static Documents (Mandatory and Optional Enclosures) are passed as Adobe 
PDF Files, which are transported and catalogued separately. 

The power of Access Reports places few limits on the printed scope of the Statements that a 
Statement Originator can define. Non-print objects, such as sounds, video, web links, etc., 
are included as binary objects within a PDF file.. 

See Figure 55 - The Statement Template on page 16 for a definition of a Statement Template.. 

1 . Statement Template ID 

A Statement Template is identified by a Statement Template Number, "T" + a 
Visa assigned 7 digit number (e.g.: T0000001), and a Template Version 
Number, a Visa assigned 4 digit number (e.g.: 1033). Together, separated by 
a Y, they form a Statement Template ID, (e.g.: T0000001vl033). 

Statement Templates are referenced by the Template Data 

Template Index Table (see page 41). 

2. Template Resource ID 

Every resource file used by a Template is assigned a Template Resource ID. 

Statement Template Number + "J*+ Template Resource Number. Assigned 
sequentially. E.g.: T0040456_0031. 

Template Resources are independent of Template Version Number. That is, 
any version of the Template can reference any Template Resource. 

Examples of Template Resources: T0040466_0031.wav (sound file), 
T0040456_0032.pdf (PDF File), T0040456_0033.fon (font file), etc. 

3. The Standard Template 

A Standard Template (*.mdb file) will be delivered as part of each ESP 
Template Generation Workstation to assist in generation of Templates. This 
Template will have a simple Statement Content Table Definition describing 
the fields defined in the Statement Index File (see page 42), and will produce 
a one-page Mini Statement. 
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4. Incremental Template Updating 

Statement Originators are expected to make some change to their Templates 
with each billing cycle (e.g., monthly). Since each Template is an integral 
* mdb file, typically ranging between 0.5 and 1.5 mB in size, a full update of 
these Templates across the system would be prohibitively costly, particularly 
when the full update must be broadcast to tens of CSPs. 

Hence, one requirement for ESP design is that Template updating be 
efficient in terms of data communication. That is, we want to ensure that 
only changed data is transported with each update, and that unchanged data 
is not transported unnecessarily. A second requirement is that pre-pilot 
coding effort be minimized to reduce schedule risk. 

For commercial scale operations, the update procedure will be as follows: 

• The initial version of a Template (e.g., T1234567v0000) will 
contain all necessary elements within one * mdb file. 

• Any changes whatsoever to this Template will cause the ePay 
Switch to issue a new version number (e.g., T1234567v0001), 

<» Changes will be passed as * mdb files also; however, only those 
elements in the Template that haye been changed will need to be 
included. Since these *.mdb files will contain only changes to 
code modules, they can be compressed to very small size. 

o These changes might include new resources (PDF files, fonts, 
etc.), new report definitions, or new code modules. 

• The update ,mdb file will be designated appropriately (e.g. 
U1234567v0001). 

A general procedure will be written to combine the existing full version with 
the new update to produce a new full version (T1234567v0001). This general 
procedure will be made available to the ESP Template Authoring 
Workstation so that the merger process can be verified by the Statement 
Originator. The procedure will also exist at the ePay Switch and at the ESP 
Statement Generation Workstation, 

a. How it Works 

When the ePay Switch receives an update Template, it first attempts 
to merge the update with the existing full Template and validate the 
result. If this is successful, then the ePay Switch saves both the new 
full Template and the update as two distinct .mdb files, and sends an 
Ack response to the ESP Statement Origination Workstation. If this 
is unsuccessful, then the ePay Switch sends a Nak response to the 
update request. 

Statement Content Records passing through the Statement 
Origination Workstation are stamped with the version number of the 
Template processing it. When Statement data with the new 
Template version is received at an ESP Statement Generation 
Workstation, a new Template must be pulled from the ePay Switch. 
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If the Statement Generation Workstation has the moat recent prior 
Template stored locally (e.g.: T7654321v0056, when it needs 
T7654321v0057), it can request just the update .mdb file. Otherwise, 
it must request the full .mdb file. Two different ADV messages are 
provided to indicate the nature of the request. 

b. For the ESP Pilot 

Notwithstanding the preceding, this incremental Template updating 
capability may be stubbed out for pilot to minimize schedule risk and 
since data flows will be low. 

That is, Statement Generation Workstations will ALWAYS request 
full updates, and the ePay Switch will respond to BOTH update and 
full requests with full Templates. 

That way, as Pilot systems are converted to production capability, no 
errors will occur. 

C. ESP System's Data Transmissions 

The ESP System moves Statement Content Records and Admin Messages from the ESP 
Statement Origination Workstation to the ePay Switch and from the ePay Switch to the ESP 
Statement Generation Workstation. 

It also moves Admin Messages in the other direction. This traffic is in one of three forms* 
Statement Content Records, Simple Admin Messages, and Complex Admin Messages. 
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The following examples show Microsoft's Exchange Client, a user interface to Exchange. 
ESP will do much the same things, but under program control. 

1 . Statement Content Records 

Statement Content Records travel in Sets. A Statement Content Record Set is 
all of the records needed to generate a single Statement. Several of these 
Sets (up to some specified limit, say 5,000 - depending upon e-mail efficiency) 
are transmitted to a single CSP at once. 

See The ESP Statement Origination Workstation on page 53 for a complete 
description of Statement Content Record transmission. 

Note: this e-mail example contains two enclosures: ASCII Piles 
T1234567vl006.txt & T1234567vl006Jtems.txt. 




^ligF SPArcflive ' . Se , nder -Archfve . pj 



mmw**m f ™* * 1 47904833 - Statement Content Records • Hash 798432890 



T1234567v0506lxt T1 234567 v1 006 Jems ixt 
Template T1 234567V1 006 

T1234567v050Sixt , has 5,000 records 
T1 234567V1 006 Jem/ixt has 1 3,454 records 



T3. 




Figure 6 - A Statement Content Record E-Mail 

Simple Administrative Messages 

These e-mail messages are generated one line at a time - each line is one 
message. 

They are transmitted when they reach some limit of records, when an urgent 
event occurs, or when a Request End-of-Day Shutdown Admin Message is 
received. 

Note the "Type" column. "SCR" is "Statement Content Records", "Tlx" is 
"Transmission Index" , and "ADV is "Administrative Messages, Visa 
Format?. Other possibilities include TAk" - "Transmission 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 22 



ESP System Architecture 



Acknowledgment* \ and all of the simple of the ADVs defined in the UBF - 
Universal Biller File on page 28. It is not necessary that this column be 
restricted to 3 characters. 



!&><!m£W ■:• Mlc<osbft Gschamje - 




-.-..« 1 47904099 ■ Metsagu Sent ■ Hash 321 7B992 



To Xmn U 

C01234323 147904633 

ESP Archive 147904834 

C00234123 147904635 

C00987132 147904836 

ESP Archive 147904B37 



Date £ Time Type Hash 

199B-07-06 14:33 SCR 798432980 
1998-07-06 14:33 Tlx 393930954 
1990-07-06 14:34 ADV 003240243 
1998-07-06 14:34 SCR 793128326 
199B-07-06 14:34 Tlx 828131932 



Recrd Encl Syces 



1, 



100 
100 
100 
100 
100 



1667 
0 
0 

1851 
0 



Wnn-m- ,,,,. ,, 



Figure 7 - Simple Administrative Messages E-Mail 
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3. Complex Administrative Messages 



These E-Mails are one message each. Their data can be ASCII text, as in the 
figure below, or binary enclosures, such as Statement Templates or Template 
Resource Files. 




Figure 8 - Complex Administrative Message E-Mail 



Properties of All Electronic Mail Transmissions 

As can be seen in the previous examples, all transmissions have the 
following properties: main destination CTo"), copy destination ("CC"), 
Transmission Number (Xmn #), Title, and Hash TotaL 

a. Main Destination ("To") 

For Statement Content Records, this will be the Customer's CSP ID. 
For Admin Messages (ADV), this will be a CSP ID, a SSP ID, ESP 
Transmission Control, ESP Archive, or ESP Template Control. 

b. Copy Destination ("CC") 

For Statement Content Records, this will be ESP Archive. 

c. Transmission Number (Xmn #) 

This is a sequential number unique within each transmitter. 
Concatenated behind the transmitter's identification ("ePaySw", SSP 
ID, or CSP ID), this forms a system-wide unique identifier. 

If forms the first part of the message's Subject line. 

E.g.: "Xmn # 147904834 - Template Update - Hash 32178992" 
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d. Title 

What this transmission contains. 

It forms the second part of the Subject line. 

E.g.: *Xmn # 147904834 - Template Update - Hash 32178992" 

e. Hash Total 



o 

O 5. Duplicate File Control 

Us 

The following section applies to all parts of the ESP System sending 
e-mail messages. 

To ensure that e-mail messages are not sent more than once by mistake, the 
Transmission Log (see page 46) is kept. This is a record of each 
transmission and its hash total. 

Before a message is queued for sending, its hash total is compared to all of 
those on the table. If a match is found, the message is sent to a suspense 
mailbox and an operator message is generated. 

To be transmitted, the message must be manually requeued by the operator. 

£ 6. ESP Transmission Control 

07 The following section applies to all parts of the ESP System sending 

e-mail messages?' 

ALL e-mail messages sent MUST be accompanied by a Transmission Sent to 
ePay Switch ADV sent to the ESP Transmission Control mailbox. This ADV 
includes a hash total calculated from pre-determined values within the 
message. 

In addition, ALL e-mail messages received MUST be accompanied by a 
Transmission Received from ePay Switch ADV to the ESP Transmission Control 
mailbox. This ADV also includes a hash total calculated from the same pre- 
determined values within the message. 

During normal operation, when an e-mail message is generated, it is copied 
into the generation workstation's "Sender Archive" mailbox. 

When the ESP Transmission Control mailbox receives a Transmission 
Received ADV corresponding to a valid Transmission Sent ADV, with the same 
hash totals, it forwards the ADV to the workstation that originally generated 
the message. Upon receipt of the Transmission Received ADV, the workstation 
deletes the original message from its "Sender Archive" mailbox. 

If delivery of the message fails for some reason, a "Message Not Delivered" 
message is sent to the workstation. Receipt of this message results in 



Each type of message will have a rule for generating a hash total. 
For Statement Content Record, transmissions, it will be the addition 
of the ASCII values of one or more of the Statement Index fields (see 
page 42). 

It forms the third part of the Subject line. 
E.g.: "Xmn # 147904834 - Template Update - Hash 32178992" 
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notification of the operator and automatic re-transmission (up to a pre- 
determined number of times). 

In this way, delivery is assured. 

7. ESP Archive 

A requirement of Visa switching systems is that all traffic through them 
must be available for auditing purposes for some pre-defined period of time. 
This is accomplished at the ePay Switch via the ESP Archive mailbox. 

Rather than slowing down processing of message traffic with mail robots 
^ (Visual Basic programs manipulating e-mail messages via MAPI - Messaging 

^ Application £rogramming Interface) reading every message, significant 

W messages are forwarded to the ESP Archive mailbox, where they are stored 

y for later research. 

— f 

q AH Statement Content Record Messages are stored in their entirety. For 

^ each such message, a separate Transmission Index Message is also sent to 

tne ESP Archive mailbox. This message is an index showing the CBANs 
represented within each Statement Content Record Message. 

fy The Standard Statement Rendering Tool (see page 49) can then be used to 

JO recreate ANY Statement that passes through the ESP System. 

Q 

j3 8. End-of-Day Processing 

7 To en sure that all e-mail transmissions are accounted for, the entire ESP 

^ System will be closed for a period each day, during which traffic reporting 

!!l will be performed. 

a- The ePay Switch Initiates End-of-Day Processing 



fri 



The ePay Switch initiates End-of-Day Processing by sending a 
Request End-of-Day Shutdown ADV to each ESP Statement 
Origination Workstation and to each f£SP Statement Generation 
Workstation in the system which has not already sent in an End-of- 
Day Shutdown ADV. 

The Workstations Respond 

The Workstations can perform End-of-Day Processing in one of two 
ways: 

• by waiting for the Request End-of-Day Shutdown ADV 
from the ePay Switch before stopping processing and 
sending their End-of-Day Shutdown ADV, or 

• by sending an End-of-Day Shutdown ADV when they 
have finished their day's processing, and then shutting 
down. 

The ePay Switch Reports 

Once End-of-Day Shutdown ADVs have been received from all 
workstations, the ePay Switch will stop processing newly received 
messages and will generate its End-of-Day Reports. These reports 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 26 



ESP System Architecture 



will include a traffic analysis for each workstation (messages 
received + messages stored = messages sent + messages on hand) and 
other reports. 

Each workstation will then be sent its End-of-Day Report. 

d. The ESP System Restarts 

Those workstations left running will sign on to the ePay Switch and 
look for their End-of-Day Report messages. If they do not find it, 
they will try again later. 

Workstations which sent their End-of-Day Shutdown ADV's before 
receiving the ePay Switch's Request End-of-Day Shutdown ADV, and 
which were shut down, will look for their End-of-Day Report message, 
upon starting up. 

Once the End-of-Day Report message is received, operations will 
proceed. 

Comparison of the End-of-Day Report from the ePay Switch and the 
workstation's own End-of-Day Report is a manual operation 
performed by the workstation's operators. Any discrepancies must 
be dealt with manually. 

e. Potential Problems and Their Effects 

The ESP System has three kinds of data transmissions: 
Administrative Messages (ADV), Templates, and Statement Content 
Records. 

The following potential problems have been identified: transmission 
not received, transmission received more than once, transmission 
garbled. 

Each of these errors are detected and corrected my Microsoft 
Exchange. In addition, the ESP System will check itself, as follows: 

. All transmissions are copied to a local holding area AND they 
and their hash totals are recorded at the Transmission 
Control mailbox at the ePay Switch. 

Upon receipt, the hash totals are checked and the 
Transmission Control mailbox is notified. It, in turn, notifies 
the sending workstation, which deletes its copy of the 
message from its local holding area. 

i. Transmission Not Received 

(a) Detection 



During End-of-Day Processing, transmissions are left 
in the local holding area OK the Transmission 
Control mailbox is out of balance. 



(b) 



Correction 



Locate the lost message. Re-transmit if necessary. 
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Transmission Sent More Than Once 

(a) Detection 

Each transmitting workstation keeps a Transmission 
Log (see page 46), recording each transmission made 
with its hash totals. Detection of a duplicate hash 
total will cause the transmission to go to a suspense 
mailbox where the workstation operator will have to 
manually release it. 

(b) Correction 



(i) Administrative Messages (ADV) 

Each ADV message will have to be examined 
and a strategy developed to handle duplicates. 

(ii) Templates 

Duplicating a Template transmission will 
have no effect. 



(iii) Statement Content Records (SCR) 

Duplicate SCR transmissions will be rejected 
by the ESP Statement Generation 
Workstation via referential integrity errors. 

IN. Transmission Garbled 

(a) Detection 

/ A pre-defined hash total is calculated for each 

message before it is transmitted, and it is appended 
to the message's Subject line. 

Upon receipt, the same hash total is re-calculated. It 
the two totals do not match, an error has been 
detected. 

(b) Correction 

i. Notify the workstation operator. 

ii. Request a re-transmission. 
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D. ESP's Data 

1 . Statement Originator Data 

a. UBF - Universal Biller File 

This is the definitive list of Statement Originators and Statement 
Originator relationships. It is extracted by the ePay Switch which 
uses it to generate the ESP Template I Originator Table for the ESP 
Statement Generation Workstation and the ESP Statement 
Origination Workstation, and the Statement Originator Xref Table 







iur its uwii use. 






5 


Key 


UBFBiUerW 


Text 12 


Unique Visa-assigned number 






Expiration Date 


Date 




m 




Effective Date 


Date 








SSPID 


Text 16 


"B" & Unique Visa-assigned number 






Statement Originator Name 


Text 




??■ 




Statement Delivery Notification 
Flag 


Yea/No 


Does Statement Originator want to know 
when Customer downloads Statement ? 
SeeADV#8-8d 






Paper Statement Option 


Textl 


"1": Always Mailed 
"2": Never Mailed 










a 3 w : Mailed at Customer request only 
"4": Not Mailed at Customer request only 


--=^ 
.n 




.Who Authorizes Customers ? 

(Statement Originator Capabilities 
Parameter: byte 1 of 24) 


Textl 


"A": All Customers can sign up 
"B": SSP will confirm Customer sign up 
"E": ESP will confirm Customer sign up 
See ADV#1 


m 




Full Statement Device Option 


Text 2 


"CD": Conforming Devices only 
"ND": Non-Conforming Devices only 
"CN": Both Conforming & Non-C devices 
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b. SSP Template/Originator Table 

Generated by the ePay Switch from the UBF and the Template 
Index File for the ESP Statement Origination Workstation, this table 
contains Statement Originators who are ESP Active. 

The Template OK field must be "Yes" and the UBF Expiration Date 
must not be passed before Customers can request ESP delivery of a 
Statement or Statement Content Record Sets for this Statement 
Originator can be passed from the ESP Statement Origination 
Workstation to the ESP system! 

The Template OK field is set when the Statement Originator 
successfully registers a Template with the ePay Switch. It is cleared 
if the last valid Template expires. 

Since Statement Content Record Sets can only be held for a short 
period of time at the ESP Statement Origination Workstation, 







„^„ , 


mpiaze sLS soon as possible is imperative. 
^mmenU ... ■ ■ ■ 1 


Key 


Template ID 


Text 8 


A Unique Visa-assigned number 
identifying a Statement Template. T & 7 
digits. E.e.: T1234567. 


Alt Key 


UBF Biller ID 


Text 12 


Unique Visa-assigned number 


Alt Key 


SSPBillerlD 


Text 16 


Number that the SSP knows the 
Statement Originator by 




SSP ID 


Text 12 






UBF Expiration Date 


Date 






UBF Effective Date 


Date 






Template Name 


Text 






Statement Originator Name 


Text 






Statement Delivery Notification 
Flag 


Yes/No 


Does Statement Originator want to know 
when Customer downloads Statement ? See 
ADV #8-8d 




Paper Statement Option 


Textl 


"1": Always Mailed, 
"2": Never Mailed, 

"3": Mailed at Customer request only 
"4": Not Mailed at Customer request only 




Customer Sign Up 

- Statement Originator 
Capabilities Parameter: 
bvtelof24 


Textl 


*A W : All Customers can sign up 1 
"B": SSP will confirm Customer sign up 
See ADV #1 




Template OK 


Yes/No 


Is this a valid Template ? | 
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c. CSP Template/Originator Table 

Generated by the ePay Switch from the UBF and the Template 
Index File for the ESP Statement Generation Workstation, this table 
contains Statement Originators who are ESP Active and their 





>• Field -v^ - <^ - ^\< 






Key 


Template ID 


Text 8 


A Unique Visa-assigned number 
identifying a Statement Template. "T" & 7 
digits. E.cr.: T1234567. 


Alt Key 


UBF Billet ID 


Text 12 


Unique Visa-assigned number 




SSPID 


Text 12 






UBF Expiration Date 


Date 






UBF Effective Date 


Date 






Template Name 


Text 






Statement Delivery Notification 
Flag 


Yes/No 


Does Statement Originator want to know 
when Customer downloads Statement ? 
See ADV #8-8d 




Full Statement Device Option 


Text 2 


"CD": Conforming Devices only 
"ND": Non-Conforming Devices only 
"CN": Both Conforming & Non-C devices 




Template OK 


Yes/No 


Is this a valid Template ? 



10 



m 



Administrative Messages 

a. ADV - Administrative Messages, Visa Format 

They will be comma-delimited ASCII records in the following basic 







From 


UBF Biller ID. or CSP ID 


To 


UBF Biller ID. or CSP ID 


Create Date Time 


Date & Time to nearest second 


ADV Type 


Which message ? 


ADV Data 


Comma-delimited message fields, dependent upon ADV 
Type 
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b. ADC - Administrative Messages, Customer Format 

These are Administrative Messages in the format required for 
communication between the CSP*s Home Banking System and the 
Customer's PC. They are neither generated nor received by ESP 
components and are outside the scope of the ESP Project. 

3. Customer Data 

a. SSP Customer Prof fie Table 

This Table is maintained at the ESP Statement Origination 
Workstation. It is passed on to the SSP where it is used to extract 
SAR Statement Record Sets for ESP delivery from the main Print & 
Mail data stream. 

All changes must be authorized by the SSP or Statement Originator. 
Note that the CSP Account Number, the number that the CSP knows 
the Customer by, may be considered confidential by some CSP's (for 
example, it may be a bank account number). As a result, the 
combination UBFBiUerlD & CBAN is used to uniquely identify a 
Customer. 















Key 


UBFBiUerlD 


Text 12 


Unique Visa-assiffned number 




Key 


CBAN 


Text 12 


How' the Statement Originator knows the 
Customer 




Key Deo 


Expiration Date 


Date 








Effective Date 


Date 




-n 




Template Number 


Text 8 


Note: No Template Version Number 






CSP ID 


Text 7 


W C & Unique Visa-assigned number 






Test Account Flag 


Yes/No 


Used for SSP Teet runs 






Advertisments Reauested 


Text5 


Value assigned bv SSP via ADV 






Hard Copy 


/Yes/No 








Hard Copy Until ^ 


Date 
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b. CSP Customer Profile Table 

This Table is maintained at the ESP Statement Generation 
Workstation. 

All changes will be triggered by receipt of a "Customer Statement 
Delivery Ack n or "Customer Statement Delivery Ack n ADV at the 
Workstation. 

Note that the CSP Account Number, the number that the CSP knows 
the Customer by, may be considered confidential by some CSP*s (for 
example, it may be a bank account number). As a result, the 
combination UBFBiller ID & CBAN is used to uniquely identify a 
Customer, 



m 




•:■..;>,.■: '.. v Vr". 


Type 






Key 


UBFBiller ID 


Text 12 


Unique Visa-assigned number 


0 


Key 


CBAN 


Text 12 


How the Statement Originator knows the 
Customer 


m 


Key Dec 


Expiration Date 


Date 




pj 




Template Number 


Text 8 


Note: No Template Version Number 




Alt Key 


CSP Account Number 


Text 20 


. Specified by CSP. Not currently used by ESP. 


m 




Teat Account Flag 


Yes/No 


Used for SSP Test runs 






Advertisments Requested 


Texts 


F — 


o 




Display Full Graphics 


Yes/No 








Summary Statements 


Yes/No 








Detailed Statements 


Yes/No 
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4. Template Data 



a. Template Index Table 



Key 



Key Dec 



m 



uf 



ThiB table is maintained by the aPay £wOcA and downloaded 
to the ESP Statement Origination Workstation and ESP 
Statement Generation Workstation (SGen). 



Template Version 

Number 



Effective Date 



Expiration Date 



SSPID 



UBF Bitter ID 



Status Flag 



Text 8 



Text 4 



Date 



Date 



Text 7 



Text 12 



Textl 



A unique Visa-assigned number identifying 
the Statement Template. *T" & 7 digits. 
E.g.:TP040456 



A Visa-assigned number identifying a 
version of the Statement Template. 4 
digits. E.g.: 1056 



Required date 



May be Null 



'B" & Unique Visa-assigned number 



Unique Visa-assigned number 



"A": Number Assigned but no Template 
a E": Template Certification Error 
a O B : Template On Site {SGen only) 
"P": Template Pending Certification 
"R": Download Requested (SGen only) 
a S": Template in Service 
T: Template in Test Service 
"X": Production Error 1 



5. Statement Data 



a. SLR - Statement Legacy Records 

The records sent to the SSP by a Statement Originator to generate 
Statements for a given Statement Cycle Date. 

SLR records are split into two streams by the SSP: those for 
Customers whose Statements are to be printed, and those for 
Customers whose Statements are to be delivered by the ESP Service. 

Note that for the pilot, all Statements delivered by the ESP Service 
will also be printed. In addition, some Customers may elect to have 
their Statements both printed and delivered electronically. 



b. 



SAR - Statement Legacy Records, Augmented 

To be processed by the ESP System, Statement Content Records must 
contain all of the data defined by the Statement Descriptor (see page 

Any of this data not supplied by the Statement Originator must be 
added by the Statement Service Provider (SSP), much of it from the 
Customer Data 

SSP Customer Profile Table (see page 39). 
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This data may include: 

• Template ID = Template Number &*v m & 

Template Version Number 

• UBFBiUerlD 

• CSPID 

• CBAN 

• Statement Cycle Date 

• Late Payment Date 

SAR records will be passed to the ESP Statement Originating 
Workstation in the form of comma-separated files (CSV) for 
processing. 

c. SCR -Statement Content Records 

These are SAR records which have been re-packaged for 
transmission to The ePay Switch, according to the definitions in the 
Statement Template, into comma-delimited records for optimal 
transmission efficiency. They are loaded into SQL tables by the ESP 

j^f Statement Generation Workstation. 

M 

— a 

d. Statement Descriptor 

O The minimum data required by the ESP System to be included with 

a Statement 

* 3 ™ 8 data is used by the CSP to generate a Mini Statement for the 

^ Customer and to allow the Customer to pay the Statement through 

^ the ePay system. 

O 0fcher and associated sets of Descriptor variables will be added in 

yj response to Statement Originator demand. 



Q 

01 
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Each record has the following fields (Note that since this is a comma- 
delimited ASCII file, texl 



— 


■TO* t_I 




Comments £ 


Key 


template ID 


Text 


Template Number & "v" & Template 
Version Number 


Key 


CBAN 


Text 




Key Dee 


Statement Date 


Date 






CSP Account Number 


Text 


HnW til A C!SP lrnnwn frlio Cuatnmor 




UBFBiUerlD 


Text 






Late Payment Date 


Date 






Statement Delivery 

IVUll] tGUiiwn r ULg 


Yes/No 






Customer Name 


Tort 

i. CAL 






Customer Address I 








Customer Address 2 


Toy* 

1 DAL 






Customer City 


1 CAL 






Customer State 








Customer Country 


Text 






Customer Postal ZIP Code 


Text 






Statement Type 


Toy*- 1 


t\ —> Auvjsury message 
*T* = > Invoice 
"S" => Account Summary 




Message Type 


Text 


Advisory Message Only 




Message Text 


Text 


Advisory Message Only 




Sender Name 


Text 


Advisory Message Only 




Sender Title 


Text 


Advisory Message Only 




Sender Address 1 


Text 


Advisory Message Only 




Sender Address 2 


Text 


Advisory Message Only 




Sender City 
J 


Text 


AHvinrkT*v ^Aoaancro Onlv 
xxvi Y xoyjL y l?.l&E9BcU£t3 \Jklly 




Sender State 


TVxfr 


ritiviHury iviessage vyniy 






Text 


Advisory Message Only 




oenaer costal KsOae 


Text 


Advisory Message Only 




oenaer telephone 


Text 


Advisory Message Only 




Sender Fax 


Text- 


Advisory Message Only 




Sender E-Mail 


Text 


Advisory Message Only 


Total Amount Due 


Currency 


Invoice Only 




Minimum Amount Due 


Currency 


Invoice Only 




Past Due Amount 


Currency 


Invoice Only 




Current Charges 


Currency 


Invoice Only 




Finance Charges 


Currency 


Invoice Only 




Other Fees 


Currency 


Invoice Only 




Credits & Adjustments 


Currency 


Invoice Only 




Previous Payment 


Currency 


Invoice Only 




Previous Payment Date 


Date 


Invoice Only 




Payment Due Date 


Date 


Invoice Only 




Late Payment Date 


Date 


Invoice Only 




Current Balance 


Currency 


Account Summary Only 




Previous Balance 


Currency 


Account Summary Only 




Deposits & Investments 


Currency 


Account Summary Only 




Withdrawals <fc Debits 


Currency 


Account Summary Only 




Service Charges 


Currency 


Account Summary Only 




Interest & Dividends 


Currency 


Account Summary Only 
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Previous Statement Date 


Date 


Account Summary Only 




Account Description 


Text 


Account Summary Only 




Current Period Yield 


% 


Account Summary Only 




Year to Date Yield 


% 


Account Summary Only 



e. INF - Statement index 



One record for each Statement, 











dOfttlft0lM^ i i 




Key 


Statement Descriptor 




See Statement Descriptor, above 






Status 




For ESP use only. 


m 

H 

Q 

5 
□ 

1 








Used during Statement Generation to 
control the processing of the Statement. It 
is one of the following: 

• Awaiting Processing 

• Awaiting Template 

(from ePay Switch) 

• In Generation Queue 

• Template Error 

• Data Error 

• Generated 

• Archived 


-B 

m 

5 




Fully Rendered 

Statement 
PDF File Name 




for ESP & CSP uae 


M> 




Generation Date 


Date 


Date that the Statement was generated. 






Pull Date 


Date 


Date that the CSP took delivery of Statement 


□ 




Push Date 


Date 


Date that Customer downloaded Statement 



m f ■ Statement Download Log 



If a Statement Originator has scathe Statement Delivery Notification 
Flag on the CSP Template / Originator Table (see page 30) via the 
UBF, or on the Statement Descriptor (see page 42); an ADV message 
is sent to the ESP Statement Origination Workstation each time a 
Statement is Pulled, Pushed, or Pulled & Pushed by the CSP. 

These messages are generated as part oiEnd-ofDay Processing (see 
page 25). 

i. Pull 

The CSP Pulls a Statement by issuing the Statement 
Download Req: Pull All ADV to receive and manage all 
available Statements. 

See Statement Batches Solution on page 72. 
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II. 



Push 



Key 



Key 
Key Dec 



The CSP Pushes a Statement by downloading it to a 
Customer. 

Sending this ADV is REQUIRED when the CSP chooses the 
Statement Batches Solution. 

III. Pull & Push 

The CSP can Pull & Push at the same time. The Statement 
Download Reg: Pull & Push ADV is used to request 
Statements one at a time. 

See The Individual Statements Solution on page 71. 
This log file will be made available to the SSP for m^ry purposes 



SSP Biller ID 
CBAN 



Payment Due Date 



Generation Date 



Pull Date 



Push Date 



Text 12 



Text 12 



Date 



Date 



Date 



Date 



SSP-assigned number, unique for SSP 



How the Statement Originator knows the 
Customer 



Payment Due Date of Statement 



Date that the Statement was generated, 



Date that the CSP took delivery of Statement 



Date that Customer downloaded Statement 



Transmission Data 



Key 



Template ID 



Transmission Index 

For each Statement Content Record Transmission from SSP to CSP 
a Transmission Index is sent to the ESP Archive mailbox. 

The Transmission Index is used by ESP Archive to determine which 
transmissio n contains an individual Customer's Statement. 



Text 12 



Template* + V+ Template Version # 
E.g,:T0040456vO051 



Key 



CBAN 



Text 12 



How the Statement Originator knows the 
Customer 



Key 



Statement Cycle Date 



Date 



Alt Key 



Alt Key 



SSP ID 



Text 7 



Transmission Number 



Long_ 



SSP ID + Transmission Number form 
unique key 



UBF Biller ID 



CSP ID 



Text 12 
Text 7 



Unique Visa-assigned number 



Record Count 



Integer 



"C & Unique Visa-assigned number 



Number of records in this Transmission 
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m 



b. Transmission Log 

For each transmission 
Transmission Log rec 

This Log kept by the transmitter and is used to detect duplicate 



For each transmission sent by SSP, CSP, or the ePay Switch, a 
Transmission Log record is generated. 



; 


Meld "y - 




Type 




Key 


Destination 


Text 


To" line of mail message 


Key 


Title 


Text 


From "Subject'' line of mail message 


Key 


Hash 


Long 


Hash total for message 




Transmission Number 


_Long_ 






Transmission Date 


Date 






Record Count 


Integer 


Number of records in this Transmission 



Fy 
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E. ESPs Processes 



•TFL 
l 

Visa's ESP 
Template 
Authoring 



1 . The ESP Template Authoring Workstation 

The ESP Template Authoring Workstation is used to \ 
generate and maintain Statement Templates. It is '. 

operated by the SSP in conjunction with the ESP n=±r 

Statement Origination Workstation. \£u 

It is a. Visual Basic program which calls Microsoft * = * Workstation 

Access to define and update the Access Report and 
r; SubReports that make up the Statement Template. All Template 

ijj development, including SAR Stream Parsing and Report definition is done 

using Access. 

H See page 16 for a description of the contents of the Statement 

2 Template. 

U Generation of a new Statement Template will include the following steps: 

^ a) Request a new Statement Template Number from the ePay 

^ Switch. 

p b) Define the Statement Content Tables: the tables and their fields 

needed to store the data of the Statement. This is done using an 
^ Access Wizard to generate Access Tables (Development may be 

j" 1 deferred). 

Statement Content Tables' names contain the Statement 
Q Template Number and the Template Version Number of the 

p Template where they were defined. 

For example, Template T1234567v0123 may contain tables 
T1234567v0123 f T1234567v0100_Service, T1234567v0020_ATT 
T1234567v0003„MCI, etc. 

Table T1234567v0099_Service would be obsolete and 
automatically deleted from ESP Statement Generation 
Workstations when its last data is purged. 

c) Map the SLR Stream to the Statement Content Tables. The VB 
program reads the Access Tables and shows a Form which allows 
the user to define the mappings via drag-and-drop, depending 
upon the type of SAR Stream (SQL Table, Fixed-length, 
Delimited, or Print Image) (Development may be deferred). 

d) Generation of the Transmission Format mapping is automatic 
(Development may be deferred). 

e) Enter both typical and pathological Test Data. These data will 
be used to develop and test the Statement Template. Different 
conditions can be developed with data for several different 
months. 

See ESP Test Mode on page 71. 

a) Write the Access Report, using the Test Data to verify that the 
Report meets the Statement Originator's expectations. 
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b) Place the new Statement Template onto Test Service with the 
ePay Switch (ref: Statement Template in Test Service Reg ADV 
on page 36). If the Switch reports any errors, resolve them and 
re-load. 

c) Sign-on to the various CSP Test Accounts and terminate and 
activate the Statement Examine the test results. 

d) Once the Template produces the required results, place the new 
Statement Template onto Service with the ePay Switch (ref: 
Statement Template in Service Req ADV on page 36). 

Maintenance of existing Statement Templates is done in essentially the same 
f= way. 

2 a. Data Stored 



3 



The current Statement Template MDB File, Statement Stationary, 
and any other binary resources needed for Statement generation, ' 
such as fonts; Generic Enclosures, etc. In addition, a copy of the* 
Standard Template should be kept on hand. 



b. Processes 



m Workstation 



Request a new Statement Template # from the ePay Switch. 
This will be done via the ESP Statonent Origination 



v 



ii. Remove a Statement Template from Service. This will be 
done via the ESP Statement Origination Workstation. 

iii. Display a Statement in final form from the test data. 

iv. Define the SAR Parsing Table. 
Define the Transmission Parsing Table (will be automatic). 

vi. Assemble the Statement Resource Set, including the ' 
. Statement Stationary. 

vii. Define the Report and SubReports. 

viii. Place a Statement Template into Test Service. This will be 
done via the ESP Statement Origination Workstation. 

ix. Place a Statement Template into Service. This will be done 
via the ESP Statement Origination Workstation. 

x. Place a corrected version of a Template into Service. 

Hardware 

i. Pentium PC with 32 mB RAM, 2gB hard disk, floppy, backup 
device, CD-ROM, 28.8 kbs modem/keyboard, mouse, 17* 
monitor and sound system. 

ii. LAN Connection with ESP Statement Origination 
Workstation. 
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d. Software 

i. Operating System: Windows NT Workstation. 

Winl6 operating systems such as Microsoft Windows 
for Workgroups® are not acceptable, since they cannot 
run the software needed. 

ii. Microsoft Access v7.0. 

iii. Desktop Publishing program capable of generating Statement 
Stationary and bitmaps. 

CorelDRAW and Micrografx Designer vector-based files can 
be used by Access directly and will both save transmission 
size and improve final appearance. 

iv. Adobe Exchange® v3.0 

v. Visa's ESP Template Authoring Workstation software. 

2. The Standard Statement Rendering Tool 

Software designed to generate a Statement using the Template, and data 
from one of four sources: 

■ 1. Test data from within the Template, 

2. "Production" data from our SQL Server database on the 
Statement Generating Workstation, and 

3. "External* data residing in an ODBC compliant database under 
the control of a CSP or SSP's Customer Service Group, 

4. Archived data residing on a CD: 

This tool is part of the ESP Template Authoring Workstation, the ESP 
Statement Origination Workstation, and the ePay Switch. 

Given a Template ID, CBAN, and Statement Cycle Date, it will generate a 
Full Rendered Statement PDF File andffisplay it to the operator, using the 
same engine to generate the PDF File as is used in the ESP Statement 
Generation Workstation. 

The operator of the ESP Template Authoring Workstation uses this tool to 
certify new Templates, The Statement Originator can use it for Customer 
Support calls. Visa Research can use it, in conjunction with the ESP Archive 
data store, to re-create any Statement ever passed through the ESP System 
(subject to data availability). 

3. The SSP's System 

The SSP's System will be responsible for two new 
functions: 

• Provide SAR Stream data for Statements to be 
processed by ESP (as defined by the Statement 
Originator and the Customer), with necessary 
header information. 

• Receive Admin. Messages (ADV) from the BS 




adv; 



SSFs System 
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ESP Workstation. 

Note that The SSFb System is outside the scope of the ESP Project 
It is the property of the SSP, not Visa. 

LAN or other connection is transparent to the operation of Visa's software, 
since the interface consists of the exchange of ASCII "flag files" only. 

Verification of "Customer Statement Delivery Req* and "Customer Statement 
Delivery Termination Req'ADV messages is controlled by the Customer Sign 
Up field of the SSP on page 29: 

• "A" means that all Customers can sign up. 

• means that SSP will confirm Customer sign up verification. 

a. Data Stored 

i. Statement Legacy Records (SLR). Received from Statement 
Originator. Only those SLR's indicated by entries in the 
Customer Profile Table are included, (see page 41). Some 
Statements are removed from the main print stream, and 
some are duplicated there, depending upon values in the 
Customer Profile. 




Statement Legacy Records, Augmented (SAR). Produced 
from SLR, using Customer Data 



SSP Customer Profile Table (see page 39) and Template Data 
Template Index Table (see page 41). 

v. Customer Profile (as described on page 29, but using SSP 
Biller ID, instead of UBF Biller ID). 

vi. Template Data 

Template Index Table (see page 41). 

viii. Administration Messages, Visa Format (ADV). 
(see page 28). 

b. Processes 

i. Receive SSP Customer Profile Table and Template 
Index Table from ESP Statement Origination 
Workstation. 

This new process will be developed by the SSP. The SSP 
Customer Profile Table could also be maintained by the SSP. 
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ii. Receive Statement Orlgtnator_XrefJTable from ESP 
Statement Origination Workstation. 

This new process will be developed by the SSP. 

III. Receive SLR Records from Statement Originators. 

This is an existing process, and is not affected by this project 

iv. Split SLR Records 

Split those SLR Records representing Statements bound for 
ESP from the main print stream, based upon the Customer 
Profile Table. 

This new process will be developed by the SSP. 

v. Augment SLR Records to SAR format. 

This new process will be developed by the SSP. 

The details of this process depend greatly upon the format of 
the SAR Records and the SSFs data processing 
environment. 

Template J^umber and Template_VersionJVumber will be 
added to each Statement Record Set. The 
Template JVersionJVumber will be checked by the ESP 
Statement Origination Workstation. 

This new process will be developed by the SSP. 

vi. Transfer SAR Records to ESP Statement Origination 
Workstation. 

This will be done in the form of a copy of files to and from a 
given set of subdirectories, either via a network or other fiel- 
transfer medium. 

It is new process will be developed by the SSP. 

vii. Transfer ADV File to ESP Statement Origination 
Workstation. 1 

This will be done in the same manner as SAR Records. 
It is new process will be developed by the SSP. 

viii. Receive Administration Messages (ADV) 

Receive Administration Messages, Visa Format (ADV), with 
Control Total File from ESP Statement Origination 
Workstation. 

This new process will be developed by the SSP. 
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ix. Send Administration Messages (ADV) 

Send Administration Messages, (ADV), and Control Total 
File from ESP Statement Origination Workstation. 

This new process will be developed by the SSP. 

x. Process Control Total File. 

Report any discrepancies found with actual transmission 
records. 

This new process will be developed by the SSP. 

xl. Receive Operator Messages 

When urgent or routine messages are received (as noted by 
"Pass on to SSP" comments), the SSP's operator must 
perform some action. 

These messages will be handled by a modular process, which 
can be interfaced to an e-mail system (via MAPI), console 
messages, or some other means of notifying the SSP's 
Operators. 

xli. Process Administration Messages (ADV) 

This new process will be developed by the SSP. 

(a) Receive ADV: Customer Statement Delivery Reg 
Request Statement Originator's OK 

If Statement Originator rejects then 

Return Customer Statement Delivery Nak 

with error message 
Else If this is a SSP's Test Customer Account 

Return Customer Statement Test Delivery Ack 
Else Return Customer Statement Delivery Ack 
End If 

(b) Receive ADV: Customer Statement Delivery 
Termination Req 

Request Statement Originator's OK 
If Statement Originator rejects then 

Return Customer Statement Delivery Term Nak 
with error message 
Else Set Termination Date in Customer Profile 

Return Customer Statement Delivery Term Ack 
End If 

(c) Query Statement Download Log or 

Receive ADV: Statement not Pushed by Due Date 
Take appropriate Customer Service action. 

Hardware 

Any: PC, minicomputer, mainframe, or combination. 
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m 



d. Software 

i. Any LAN that can communicate with Windows NT Server 

M g ;S TO/IP ' IBM SNA ®' Nove » Netware®, Windows 
NetBEUI®, Appletalk®, DECnet®, etc. 

ii. Any operating system that can copy files to and from a given 
subdirectory on a Windows NT Server. 

The ESP Statement Origination Workstation 

The ESP Statement Origination Workstation pc vw ' 

performs three main functions: it passes Template w^j™'*"** 
transactions between the Template Authoring WS 
and the ePay Switch, it processes an SAR Stream and 
passes it to the ePay Switch, and it passes and 
processes Administration Messages. 




An ESP Statement Origination Workstation is " ** 

p identified by an SSPJD. If the same Statement 

O f ^^er is operating from more than one site, with more than one 

SU ^ p Statement Origination Workstation, then two separate SSPJDs will 

ffl ™2 J? * ^d. In addition, each Statement Originator is identified by a 

□ WF Biller ID. If they are originating Statements from more than one SSP 

j3 Slte » tnen th ey will need more than one UBF Biller ID. 



a. Data Stored 



C i. Each current Statement Template (+mdb file) defined for the 

5f SSF 8 Statement Originators must be kept for local 

U processing. 

J Template Data 

m Template IndexTable (see page 41). Used to add 

Template JTersionJtf umber to SAR Records. 

iv. Statement Originator Cross-Reference Table (see page 28) a 
cross-reference between the SSP*s Biller JD's and Visa's ' 
UBF Biller ID's. Used to reformat SAR Records for 

. transport. 

v. The Customer Data 

SSP Customer Profile Table (see page 39). maintained by this 
workstation. 

SAR Records awaiting parsing and transport. 

Statement Content Records, parsed from SAR Records and 
awaiting transport. 

Control Total File containing transmission control totals for 
auditing. 



vii, 
viii. 

ix. 
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b. Processes 

Notes: Req = Request, 

Ack = Acknowledgment , 

Nak = Negative Acknowledgment 

i. Receive SAR Records from the SSP's System. 

Convert SSFs Biller ID to UBF Biller ID. See page 41. 

Current plans call for this to be one of the following: 

• When SAR Records are presented in SQL Tables, they 
are copied into files of comma-delimited records. One file 
for each Statement Content Table, with the table name as 
filename, and with one variable-length record for each 
table record. 

An accompanying Control Total File, consisting of one 
record for each of the data files, showing record count 
and hash totals, must be included. This file's records will 
be compared against the files received, and any 
differences will be reported. 

o When SAR Records are in other formats, the records 
themselves are presented. Transmission Control Files 
will have to be worked out with each SSP. 

These files will be copied into a given subdirectory on the 
Workstation. 

ii. Parse the SAR Records into Statement Content 
Records for Transmission. 

This will be done using, the SAR Parsing Table within the 
Statement Template. It is an entirely table-driven process, 
witjt NO code specific to the Statement Templates being 
processed. 

In the case of SQL Table-based SAR Records, this will mainly 
consist of adding the TemplateJVersionJfumber and UBF 
Biller ID and CSPJD from the SSP Customer Profile Table. 

Since the SSP has a vested interest in the fidelity of the 
Statement (after all, the Statement Originator is his 
Customer !), any labor-intensive or sophisticated processing 
should be here, rather than at the ESP Statement Generation 
Workstation. 

SAR Records for a single Statement JTemplateJt will be 
sorted and processed in order of CSPJD. 

lit. Collect Statement Content Records by Destination 

As Statement Content Records are received, they are copied 
to ASCII file sets, one set for each destination CSP. Each set 
consists of one file for each Statement Content Table in the 
set. 
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When a pre-determined number of Statements (say 100) are 
represented in any one file set, or when Statement Content 
Records are received for a new Template, that set is 
transmitted to its destination CSP, via the ePay Switch, and 
the ASCII files are emptied. 

iv. Transmitting Statement Content Records to the CSP 
via the ePay Switch. 

Each Statement Content Record Set (i.e.: the records for one 
Statement) take part in three transmissions: the Statement 
Content Record Message, the Transmission Index Message, 
and the Transmission Control Message. 

(a) The Statement Content Record Message 

Each ASCII file of the Statement Content Record Set 
is included in the Message as an Enclosure. 

See the SCR - Statement Content Records portion of 
ESP System's Data Transmissions on page 42. 

Total record counts are added for each file, and a 
hash is performed on the CBAN field of the "main" 
file. 

The CBAN field is chosen for the hash field because it 
is a required field for all Statements - see Statement 
Descriptor on page 42. 

A copy of the Statement Content Record Message is 
sent to mailbox ESP Archive, where it is stored for 
Visa Research. 

(b) The Transmission Index Message 

The Transmission Index Message is a cross-reference 
to the CBANs within a Statement Content Record 
Message. It is used by Visa Research to determine 
which Statement Content Record Message contains 
the Statement data for a given Customer. 

See the Complex Administrative Messages portion of 
ESP System's Data Transmissions on page 42. 

(c) The Transmission Control Message 

EVERY message sent via the ePay Switch must 
produce a corresponding record sent to the mailbox 
ESP Transmission Control. In addition, when ANY 
message is read from the ePay Switch, a 
corresponding record must be sent to ESP 
Transmission Control. 

Thus, ESP Transmission Control acts as a 
clearinghouse of messages, ensuring integrity and 
timeliness. 

See the Simple Administrative Messages portion of 
ESP System's Data Transmissions on page 42. 
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Receive and Process Administrative Messages (ADV) 
from the SSP's System 

A Control Total File will be needed in all cases. 

(a) Receive ADV: Customer Statement Delivery Ack 
Create BS Customer Profile 

Send ADV to CSP 

(b) Receive ADV: Customer Test Statement Delivery 
Ack 

Create BS Teat. Customer Profile 
Send ADV to CSP 

(c) Receive ADV: Customer Statement Delivery 
Termination Ack 

Update BS Customer Profile Termination Date 
Send to Customer 

(d) Receive ADV: 

Customer Statement Delivery Nak 
Customer Statement Delivery Term. Nak 

Send ADV to Customer 

Process Administrative Messages (ADV) from SSP 

(a) Receive ADV: 

ANY "Statement Template ... Request" 
Statements Not Downloaded List 
End-of-Day Transmission Query 

Send to ePay Switch 

Process Administrative Messages (ADV) from ePay 
Switch 

(a) Receive ADV: Customer Statement Delivery Reg 

If Customer Sign Up = "B" then 
Pass on to SSP 

Elself Customer Sign Up = "A" then 

Create SSP Customer Profile record 
Send Customer Statement Delivery Ack 

to Customer 

End If 

(b) Receive ADV: Customer Statement Delivery 
Termination Reg 

If Customer Sign Up = "B" then 
Send to SSP 

Elself Customer Sign Up = "A" then 

Update SSP Customer Profile record 
Send Customer Statement Delivery Termination 

Ack to Customer 
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End If 

(c) Receive ANY "Statement Template ... AcklNak" 
ADV 

Send to ESP Template Generation Workstation 

(d) Receive ADV: 

Statement Template Expires next Month 
Statements Not Downloaded List 
End-of-day Statement Transmission List 
Report to operator. 

(e) Receive Transmission Received from ePay 
Switch ADV 

Delete Message from "Sent" mailbox. 

viii. Pass Statement Templates and Admin. Messages from 
The Template Authoring Workstation to the ePay 
Switch. 

This will be a simple bi-directional pass-through, with the 
exception that a copy of all Templates currently in service for 
the SSP will be retained. 

Each receipt and transmission will be recorded in the Control 
Total File. 



/x Send Administrative Messages (ADV) to ePay Switch 

Transmissions will be made at pre-determined intervals (e.g.: 
once a day, when 100 messages have accumulated, etc.). 

x. End^f-Day Processing 

See End-of'Day Processing on page 25. 

Local traffic control reports will be generated. Details of 
their design have yet to be determined. 

xi. System Management Functions 

All messages generated by the ESP System for attention of 
SSP Operations will be sent to a modular error handler. This 
error handler can be configured to deliver its messages in one 
of several different ways: by the SSP's internal e-mail, by 
F AX, or to the ESP Statement Origination Workstation 
monitor. 



c. Hardware 

i- Windows NT "cluster" with one or more Intel-based servers 
to execute Visual Basic code. 

May range from a single Pentium® PC to a group of heavy- 
duty Windows NT servers. A significant portion of the server 
cluster must be Intel-based to execute Visual Basic code. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 58 ESP System Architecture 



□ 



A minimum system would consist of: Pentium Pro PC, 96mB 
of RAM, 8gB RAID 5 disk array, CD-ROM, keyboard, mouse, 
17" monitor, sound system, backup hardware, Windows NT 
compatible communications hardware (e.g.: telephone, 
modems, ISDN lines, dedicated lines, etc). 

ii. LAN connection to SSP's System 

iii. Connection to ESP Template Authoring Workstation. 
May be LAN or "sneaker-net". 

iv. Microsoft Exchange Server remote connection to ePay 
Switch. 

d. Software 

i. Windows NT Server. 

ii. Visa's ESP Statement Origination Workstation software. 

iii. Microsoft Exchange Client. 

iv. Microsoft SQL Server. 

v. Adobe Exchange. 

The ePay Switch 

The ePay Switch is a Visa resource, and will be 
initially operated from Visa's San Mateo facilities. 
Unlike the ESP Template Authoring Workstation 
and the ESP Statement Origination Workstation, it 
deals with ALL SSP's, and ALL CSP'b. 

It has four primary tasks: 




y3 

yj i. Move Statement Content Records ep ay switch 

from SSP to CSP. 

ii. Move Administration Messages (ADV) from CSP and SSP 
and visa-versa. 

iii. Store, validate, and log Statement Templates, and supply 
them to Statement Generation Workstations. 

iv. Move Payment Messages from ePay BBWS and OWS 
Workstations to Visa's Base II and visa-versa (outside the 
scope of the ESP Project). 

This must be done with the highest standards of integrity and reliability. 

a. Hardware 

i. A Windows NT "cluster". 

The ePay Switch will have significantly higher 
communications throughput than any other part of the 
system, since it will serve the entire ePay system, not just 
ESP. 
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A significant portion of the cluster will have to be Intel-based 
servers for the execution of Visual Basic code. 

ii. Connection to ALL ESP Statement Origination Workstations, 
ESP Statement Generation Workstations, and ePay BBWS 
and OWS Workstations. 

iii. LAN connection to a Visa Base II VAP vl0.2 or higher 
(outside the scope of the ESP Project). 

Software 

i. Operating System: Windows NT Server. 

ii. Microsoft Exchange Server® 

iii. Visual Basic run-time with MAPI connection to the Exchange 
Server, and with Jet or Microsoft SQL Server® database. 

iv. Visa's ESP ePay Switch and ESP Template Management 
software. 

Data Stored 

i. All Statement Templates defined in ESP (see page 15). 

ii. Universal BillerFile (UBF) (see page 28). 

iii. Statement Originator Xref Table (see page 28). 

iv. Template Data 
Template Index Table (see page 41). 

vi. Control Total Files for all traffic routes. 

vii. All messages sent or received, in off-line storage for 180 days. 
Processes 

Notes: Req = Request, 

Ack = Acknowledgment , 

Nak = Negative Acknowledgment 

i. In conjunction with ESP Template Authoring 
Workstations, via ESP Statement Origination 
Workstations: 

(a) Receive ADV: New Statement _Template_# Req 
Generate & record a new Statement JTemplate Jt. 
If OK then 

Return New Statement_Template_# Ack 

with new StatementJTemplateJt to SSP 

Else 

Return New Statement_Template_# Nak to SSP 
End If 
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(b) Receive ADV: Statement Template in Test 
Service Req 

Check Template. Note that this can be a new 
updated Template. This will be a largly 
manual process, involving checking the 
Template for syntactical and functional 
correctness, not for making editorial 
comments. 

In some instances, the turnaround time for 
this checking procedure will be critical to the 
successful delivery of Statements. In those 
cases, Visa has pledged to expedite this 
process. 
If OK then ,; 

Move Template to Test Download Area 
Return Statement Template in Test Service Ack 

to SSP 

Else Return Statement Template in Service Nak 

with Errors Found to SSP 

End If 

(c) Receive ADV: Statement Template in Service 
Req 

Check Template. Note that this can be a new 
updated Template (see note above re 
Checking a Template). 

If OK then 

Move Template to Download Area 
Return Statement Template in Service Ack 

to SSP 

Else Return Statement Template in Service Nak 

with Errors Found to SSP 

/ End If 

(d) Receive ADV: Stmt Template Deactivate Req 
If Date in future then 

Set Template Expiry Date 

Return Statement Template Deactivate Ack to SSP 
Else Return Statement Template Deactivate Nak 

to SSP 

End If 

(e) Receive ADV: Statement Template Expires next 
Month 

Send Statement Template Expires next Month to SSP 
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In conjunction with ESP Statement Origination 
Workstations: 

(a) Transfer Statement Content Records. 

(b) Transfer the following Administration 
Messages (ADV) to ESP Statement Generation 
Workstations: 

Customer Statement Delivery Ack INak 
Customer Statement Delivery Term Ack INak 
Statements Not Downloaded Since Date Query 



(c) 



Receive ADV: Records received from ePay 
Switch 

Receive ADV: Records sent to ePay Switch 
Save record counts for auditing 



2 lii 



End-of-Day Processing 

U See End-of-Day Processing on page 26. 

fy System- wide traffic control reports will be generated and 

g portions will be sent to the various workstations. Details of 

p their design have yet to be determined. 

J3 Billing reports will also be generated. 

m 

iv. In conjunction with ESP Statement Generation 
H Workstations: 

Q < a > Transfer Statement Content Records. 

^5 (W Transfer the following Administration 

jO Messages (ADV) to ESP Statement Origination 

Workstations: 

Customer Statement Delivery Req or 
Customer Statement Delivery Termination Req 
Statements Not Downloaded Since Date List 

(c) Receive ADV: Stmt Template Download Request 

Send Template 

id) Receive ADV: Records received from ePay 
Switch 

Receive ADV; Records sent toePay Switch 
Save record counts for auditing 

v. Download (/SFfrom Base // 

Only an extract of the full UBP is downloaded. 

vi. Transfer Payment traffic for the Customers' Bank's 
ePay Origination Wotk Station and the Billers' Bank's 
ePay BB Workstation. 

Note that this is outside of the scope of the ESP Project. 
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vii. Mailboxes: 

• One for each SSP ID = SSP ID (starts with "B"). 

• One for each CSP ID = CSP ID (starts with "C"). 

• ESP Statement Template Control 

• ESP Archive 

• ESP Transmission Control 

• ESP Statement Templates - a public folder for downloads. 

• All CSPs for Template 

viii. Mail Robots 

^ Mail Robots (Visual Basic programs with MAPI interfaces) 

^ watch certain mailboxes and process any messages arriving 

Zl there: 



=1 



=1 



ADV 



• All CSPs for Template 

Watches All CSPs for Template mailbox, and forwards 

1 message to all CSPs who have downloaded that 
iL! Template. 
if • Statement Template Control. 

Watches Statement Template Control mailbox. 
_ • Reconcile Transmission Control Files. 

2 Watches Transmission Control mailbox. Produces end- 
^ of-day reports on transmissions received and passed on. 
JO • ESP Archive. Stores all Statement Content Record and 
y i Admin Messages transmissions for research. 

H= 6. The ESP Statement Generation Workstation 

M 

p The ESP Statement Generation Workstation s ™. 

yi provides the CSFs Home Banking System with the 0PT . 

,n Statement PDF Files and associated fielded data ^ 

^ necessary to display a Statement on the Customer's ~" 

PC. It also processes Administrative Messages and 

transfers them to the ePay Switch. 

Visa's Statement ypj^- 

a. Data Stored » 

i. Statement Index (INF) - SQL 
Table 

One row per Statement. Contains Statement Index File data. 
See page 42. 

ii. Statement Content Records (SCR) - SQL Tables 

Note that the Customer can request Statements from prior. 
Billing Cycles - for a pre-defined period of time (say 6 
months). 

This data is stored in tables within a Microsoft SQL 
Server® database, not within the Template, an Access 
database (*.mdb file). Each Statement Template has one or 
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more different tables associated with it, so several thousand 
tables may be involved. 

See page 39. 

iii. Fully Rendered Statement PDF Files 

Statements prepared for delivery to the Customer will be 
either fully rendered in a single PDF File, or will be shipped 
in Statement/Stationary pairs for caching and merging on 
the Customer's PC. 

Initially, fully rendered PDF files will be produced because 
the technology to merge Statement/Stationary pairs on the 
Ul Customer's PC is not yet in hand. This can be globally 

=0 changed quite easily, once the Customer PC software has 

=| been developed. 

d s 0ne pr>F P er file * Filename is stored in the Statement Index: 

Q See page 7. 

O 

ry iv. Templates 

jjj All Templates received from the ePay Switch, Each 

J Statement Template will consist of an MDB file and one or 

mor « binary resource files such as bitmaps. These will be 
stored together in a separate subdirectory for each Template. 

It is expected that a large CSP could accumulate several 
thousand Templates. 

See page 15. 

v. Template List 

An ASCII version of the Template Data 

Template Index Table (see page 41), containing a row for 
each Template in Service, whether on-site or not. 

vi. Optional Generic Enclosures Index - SQL Table 
vil. Optional Generic Enclosures PDF Files 



vlii. Customer Profile Table 

See page 29. 

ix. Control Total File 

Contains transmission control totals for auditing. Generated 
here and transmitted to the ePay Switch. 
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b. Processes 

Notes: Req = Request, 

Ack = Acknowledgment , 

Nak = Negative Acknowledgment 

i. Receive Statement Content Record (SCR) Data 

Batches are received from the ePay Switch, parsed, and 
stored. 

This will be done into SQL tables. It will be a high-volume 
^ batch process, done by an optimized Visual Basic program 

)r with little screen interaction. 

2 H» Generate Statements in Batch Mode 

y All Statements received will be processed in batch mode 

p This will be done by a Visual Basic Program which checks 

P the Statement Index Table for newly received Statements. 

[U See Figure 33 - Generating the Fully-Rendered Statement on 

S Page 4. For each new Template, the following processing is 

O done: 

~ L If foe Template is not available locally, it is fetched 

^ ' from the ePay Switch, any new fonts are loaded, and 

f : anv other binary resources are extracted. 

O 2. All Statements for that Template are generated, as 
q follows: 

^ • The Customer-Specific Mandatory Statement is 

&s generated via calls to Access as an OLE 

m Au tomation Server, and is output as a PDF File. 

At the same time, trie PDF Merge Control Table 
(see page 16) is generated for this Customer's 
Statement. This is a list of PDF Files which must 
be appended to form the Fully Rendered 
Statement PDF File. 

The first entry in this table is usually a The 
Interactive Page PDF File (see page 12). 

• The PDF files specified in the PDF Merge Control 
Table are concatenated by Adobe Exchange, also 
- called as an OLE Automation Server. 

Once this is done, the Status of the Statement is upgraded to 
"Generated". 

As volumes increase, Statement Generation will be off-loaded 
to dedicated Windows NT Workstations, attached to the ESP 
Statement Generation Workstation by LAN. The Distributed 
Two-Phase Commit feature of Microsoft's SQL Server will 
make this possible. 
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Hi. Purge Statements 

Each day, all Statements more than x months old are purged 
from the system. 

iv. Receive Administrative Messages from CSP 

Customer Statements Available Query 

Query Statement Index to an ASCII file. 

Selection criteria is UBFBiller ID and CBAN OR 
CSP Account Number. * 

Return "Customer Statements Available List? 
message, pointing to ASCII file. 

Statement Download Request; Pull All 

Send pointers to ALL Statements that have not been 
already downloaded. Record Pull Date for all of these 
Statements. 

Statement Download Push 

ADV contains Template ID; CBAN, 

and Statement Cycle Date. 

Record Push Date for of tfiis Statement 

If the Statement Delivery Notification Flag of 

SSP (see page 29) is set 
OR the Statement Delivery Notification Flag of 

Statement Descriptor (see page 42) is set 

Then 

Generate Statement Pushed ADV 

Statement Download Request: Pull & Push 

Send pointer to a SINGLE Statement. The CSP is 
replying to a Customer's request and will Push the 
Statement immediately. Record Pull Date and Push 
Date for of this Statement. 

ADV contains Template ID, CBAN, 

and Statement Cycle Date. 

If Statement has been generated then 

Return "Statement Download Pointer" 

message, pointing to 
& Fully Rendered Statement PDF File. 

If the Statement Delivery Notification Flag of 
SSP (see page 29) is set 
OR the Statement Delivery Notification Flag 
of 

Statement Descriptor (see page 42) is set 

Then 

Generate Statement Pushed ADV 

End If 



in 



(a) 



m 
6 



(b) 
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Else If Statement PDF File has been purged, but the 
data is still available then 

Re-generate the PDF File 

Return "Statement Download Pointer'' 

message, pointing to 
a Fully Rendered Statement PDF File. 

If the Statement Delivery Notification Flag of 
SSP (see page 29) is set 
OR the Statement Delivery Notification Flag 
of 

Statement Descriptor (Bee page 42) is set 
C Then 
Ln Generate Statement Pushed ADV 

=0 End If v 

q Else Return "Statement Download Nak" message 

01 with an error message. 

y < e > Optional Generic Enclosures Download Request 

m If the Optional Enclosure PDF File is available then 

Return "Optional Generic Enclosures 
p Download Pointer* 

£l E «e Return "Optional Generic Enclosures Download" 

Nak message with an error message. 

(f) Customer Statement Delivery Req 

Edit options selected against CSP (see page 29). If 
OK, Pass on to ePay Switch. If NOT OK, report error 
to Visa - this is contrary to ESP Operating 
Procedures. 

(g) Receive other ADV from CSP 

Pass on to ePay Switch. 

v. Receive ADV from ePay Switch 

(a) Customer Statement Delivery Ack 
Update Customer Profile and pass on to CSP. 

(b) Customer Statement Test Delivery Ack 

Update Customer Profile with Test Account Flag set 
and pass on to CSP. 

(c) Customer Statement Delivery Termination Ack 
Delete Customer Profile record and pass on to CSP. 

(d) Transmission received from ePay Switch 
Delete Message from "Sender Archive" mailbox. 

(e) Other "Ack" or "Nak w ADV 
Pass on to CSP. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 67 



ESP System Architecture 



(f) Statements not Downloaded Query 

Generate and return "Statements Not Download List 1 * 
ADV. 

vi. End-of-Day Processing 

See End-of-Day Processing on page 25. 

Local traffic control reports will be generated. Details of 
their design have yet to be determined. 

c. Hardware 

i. A Windows NT server or server cluster. Unlike the other 
portions of the ESP system, the Statement Generation 
Workstation will devote a significant portion of its time to the 
generation of Access Reports. This will require one or more 
Intel-based servers. 

A typical system would include: Pentium Pro PC, 96mB 
RAM, 10 to 50gB RAID 5 disk array, CD-ROM, keyboard, 
mouse 17" monitor, sound system, communications 
hardware, backup hardware. 

ii. RAS connection to ePay Switch. 

iii. LAN connection to host CPS's HBS. 

d. Software 

i. Windows NT Server. 

ii. Microsoft Exchange Client. 

iii. Microsoft SQL Server®. 

iv. Microsoft Access 

v. Adobe Exchange® 

vi. Visa's ESP Statement Generation Workstation software. 

7. The Customer's PC 

Note that Customer's PC is outside the scope of 
the ESP Project. The hardware is the property 
of the Customer and the software is specified or 
provided by the CSP. 

The Customer's PC communicates with the CSP 
either via the Internet, Intranet, or a proprietary 
network. Proprietary network connections can be 
either on-line or off-line. 

In all cases, the free Adobe Reader is used to display the Statement. 

Future plans call for downloading of the Statement in Statement / Stationary 
PDF Sets, with the Stationary PDF Files being cached on the Customer's 



Customer/ PC 

T X PAY, 
ADC,\ ADC 
STM, v X ^ 
OPT 
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PC. This would offer significant performance advantages over downloading 
fully rendered PDF files. 

See Downloading unchanging Statement elements to the Customer's PC is 
Inefficient on page 82 

These plans are made less urgent by advances in Adobe PDF file 
compression and downloading strategies. 

a. Kinds of Customer PC Software 

The following kinds of PC Software systems are anticipated: 
HTLM/Internet, HTML/Intranet, Proprietary On-line and 
Proprietary OfF-Line. 

i. HTLM/Internet 

ThiB is the standard JKorld-Jtfide-JEeb based system. 

ii. HTML/Intranet 

As for HTML/Internet, but with a private dial-up network for 
added security. 

Hi. Proprietary On-line 

CSP's application software, written to run while connected to 
the CSP's System. 

iv. Proprietary Off-Line 

CSP's application software, written to run while NOT 
connected to the CSP's System. Data transfer is controlled 
by batch queues, which control transmission once 
communication is established. 

b. Data Stored 

Fully Rendered Statement PDF Files. 
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Processes 

1. Request a list of Statements available for ESP. 



m 
D 

I 



Notes: 



Figure 9 - A Mock-up of a Statements List 



This is a mock-up of a CSP's offering to its customers, and is outside the scope of 
the ESP System. 

The underlined words are Web links to start or stop downloading of a Statement 

This design is copied from the local Yellow Pages. Much opportunity exists for 
CSP's to improve on this layout. 
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II. Select a new Statement for ESP. 

Hi. Request Termination of Delivery of an existing 
Statement. 

iv. Request a list of Statements currently available for 
Downloading. 



Figure 10 - A Mock-up of a Statement Download Form 

Notes: 

• This is a mock-up of a CSP's offering to its customers, and is outside the scope of 
the ESP System. 

• The underlined words are Web links to download a Statement, 

• Suzie paid her September Sears statement by check, so the payment is not 
recorded here. Note that recording of ePay payments would be a CSP function 
outside the scope of the ESP System. 

• CSPs may choose many other layouts. For example, access historical documents 
may be from another Web page, reached through a button or menu item. 
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v. Request that a single Statement be Downloaded. 

For a mock-up of a Statement as it could be presented to a 
Customer, see The Statement on page 7. 

vl. Request an Optional Enclosure. 
vil. Request Payment of a Statement 

This is outside the scope of the ESP Project. 

^ d. Hardware 

Ul Any PC, Macintosh®, or Unix workstation. 

y 

=4 e. Software 

gn If the CSP is WWW based, any web browser that supports Adobe 

p Reader Plug-ins. If the CSP is not WWW based, CSFs home 

O banking software, which must support Adobe's Reader. 



ry 



8. The CSP's Home Banking System (HBS) 

Note that The CSP's Home Banking System is 
outside the scope of the ESP Project. It is the 
property of the CSP r hot Visa* 

The CSFs Home Banking System (HBS) will pass 
Admin. Messages and Statements between the 

Customer and the ESP Statement Generation 

Workstation. csr-i 




Visa's ePay System will receive payment, outside the 
scope of the ESP Project. 



Home Banking Server 



a. Methods of Operation 

Two methods of operation are offered: individual Statements and 
Statement batches. With The Individual Messages Solution, ESP 
provides management of Statements and Optional Enclosures in a 
single, unified manner; while the Statement Batches Solution allows 
the CSP to manage Statements and Optional Generic Enclosures in 
the manner best suited to their needs. 

Please note that the Individual Statements Solution still requires that 
all incoming Statement Content Records be processed in batch mode, 
and that the Statement Batches Solution does not prohibit the use of 
individual Statement requests, especially for prior-period Statements. 

i. The Individual Statements Solution 

Communication between CSFs Home Banking System and 
the ESP Statement Generation Workstation (SGen) is in the 
form of ADV messages. 
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Queries are generated by the CSP in response to Customer 
requests. 

Since these messages are originated by the Customer, who is 
waiting for their reply, they must be processed in real time at 
the highest priority. 

(a) The Query 

The following ADVs are used: 

• Statement Download Reg: Pull & Push 

• Optional Details Download Req 

• Optional Enclosure #* Download Req 

^ Note that u Pull & Push 1 * refers to the fact that the 

tfi Statement is Pushed to the Customer at the same 

^ time that it is Pulled by the CSP. 

q (b) The Response 

Jjl 1 Responses returned by SGen are in the form of 

messages containing filenames pointing to files on the 
y Workstation. 

The following ADVs are used: 
« • Statement Download Pointer 

• Optional Details Download Pointer 

tlS • Optional Enclosure #x Download Pointer 

!\ ii. Statement Batches Solution 

□ Communication between CSP*s Home Banking System and 

M the ESP Statement Generation Workstation (SGen) is in the 

■Q form of ADV messages. * 

J: SGen's response can he triggered in one of two ways: by 

u s completion of processing of a batch of newly-arrived 

Statement Content Records, or by receipt of a Statement 

Download Req: Pull Alt ADV. 

The first trigger is enabled by a parameter in SGen's 
initialization file: 

(a) The Query 

Queries are generated by the CSP in response to 
Customer requests. The following ADVs are used: 

• Statement Download Req: Pull All 

Note that u PulF refers to the fact that the Statement 
is Pulled by the CSP t 

(b) The Response 

Responses returned by SGen are in the form of 
messages containing filenames pointing to files on the 
Workstation. 

The following ADVs are returned, one for each item 
currently available but not previously reported: 

• Statement Download Pointer 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 73 



ESP System Architecture 



Optional Details Download Pointer 
Optional Enclosure #x Download Pointer 



Data Stored 



ii. 



iii. 



Customer Prof lie Table. 

See page 29. 

ESP Statement Originator Table. 

See page 29. 

Fully Rendered Statement PDF Files 



^ The CSP may choose to store and distribute all Fully 

i Entered Statement PDF Files as they are generated, by 

i 188U3n g Statement Download Reg: Pull All ADVs, or may 

S }?f ve that storage up to the ESP Statement Generation 

U Workstation and issue Statement Download Req: Pull & 

5 Push when the Customer requests a Statement. 



Processes 

I. Customer Requests a list of Statements available for 
ESP. 

Generate list from ESP Template I Originator Table (see page 

Selection criteria is UBFBillerlD and CBAN OR CSP 
Account Number. 

il. Customer Selects a new Statement for ESP. 

. Send "Customer Statement Delivery Reg" ADV. 
Receive "Customer Statement Delivery AckT. Inform 
Customer that they are signed up. Update Customer Profile. 
...OR... 

Receive "Customer Statement Delivery Nak n . Inform 
Customer that their request has been denied and show 
accompanying reason. 

iii. Customer Requests Termination of Delivery of an 
existing Statement 

Send "Customer Statement Delivery Termination Request 
ADV, with Termination Date. 

Receive "Customer Statement Delivery Termination Ack". 
Inform Customer. Update Customer Profile. 
... OR ... 
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Receive "Customer Statement Delivery Termination Nak". 
Inform Customer that their request has been denied and 
show accompanying reason. 

iv. Customer Requests a Statement 

(a) Method of Operation: The Individual 
Statements Solution 

Send "Statement Download Req: Pull & Push" ADV 
with the following fields: Statement Template #, 
CBAN, & Satement Cycle Date. 

Receive a Fully Rendered Statement PDF File (see 
page 7 for a definition) from the ESP Statement 
Generation Workstation, and pass it on to Customer. 

(b) Method of Operation: Statement Batches 
Solution 

Download Fully Rendered Statement PDF File 
previously received from the ESP Statement 
Generation Workstation, and pass it on to Customer. 

v. Customer Requests Optional Customer-Specific 
Pages. 

(a) Method of Operation: The Individual 
Statements Solution 

Send "Optional Details Download Req" ADV with the 
following fields: Statement Template #, CBAN, & 
Satement Cycle Date. 

Receive a Optional Customer-Specific PDF {see page 7 
for a definition) from the ESP Statement Generation 
Workstation, and pass it on to Customer. 

(b) Method of Operation: Statement Batches 
Solution 

Download Optional Customer-Specific PDF previously 
received from the ESP Statement Generation 
Workstation, and pass it on to Customer. 

vi. Customer Requests an Optional Enclosure. 

(a) Method of Operation: The Individual 
Statements Solution 

Send "Optional Enclosure #x Download Req n ADV 
with the following fields: Statement Template #, 
CBAN, Optional Enclosure Number & Satement 
Cycle Date. 

Receive a Optional Enclosure PDFFile(see page 7 for 
a definition) from the ESP Statement Generation 
Workstation* and pass it on to Customer. 
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(b) Method of Operation: Statement Batches 
Solution 

Download Optional Enclosure PDF File previously 
received from the ESP Statement Generation 
Workstation, and pass it on to Customer. 

vii. Customer Requests Payment of a Statement 

Outside the scope of the ESP Project. 

d. Hardware 

Any: PC, minicomputer, mainframe, or combination. 

e. Software 

i. Any LAN that can communicate with Windows NT Server, 
e.g.: UNIX TCP/IP, IBM SNA®, Novell Netware®, Windows 
NetBEUI®, Appletalk®, DECnet®, etc. 

ii. Any operating system that can copy files to and from a given 
subdirectory on a Windows NT system. 

iii. Any software that the CSP currently uses to connect with the 
Customer's PC. 

Visa's Base li 

Visa's Base 11 system will be used to transport ePay 
Payment Orders between ePay OWS andBBWS 
Workstations, and to download UBF Files to the ePay 
Switch, 



Note that, except for the downloading of UBF Files, 
connection to Vila's Base II System is outside the 1 
scope of the ESf* Project. ^ 
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F. Interfaces 

1 . ESP Statement Origination Workstation to the SSP's System 

Administration Messages, Visa Format (ADV) and 
Statement Legacy Records, Augmented (SAR) are 
passed between the SSFs System and the ESP 
Statement Origination Workstation. 

The SSFs System connects with the ESP Statement 
Origination Workstation via LAN. 

The Windows NT software of the ESP. Statement Origination Workstation 
can connect to most LANs in use today, including UNIX TCP/IP, IBM SNA, 
Novell Netware, Windows NetBEUI, Appletalk, DECnet, etc. 

Two Network Shares provided by the ESP Statement Origination 
Workstation will be the main form of communication: ToJSSP and 
FromJSSP. Data is passed in ASCII files stored in these subdirectories, or 
in subdirectories below them. 

A Network Share is a pointer to a subdirectory on a system - in this case, to 
a subdirectory on the ESP Statement Origination Workstation's Windows NT 
disk farm. 

a. Transport Mechanism 

Data is passed in ASCII files stored in two subdirectories (To J5SP 
and FromJSSP), or in subdirectories below them. Once copied, files 
are deleted by the recipient. 

i. Security 

The SSP will need a Windows NT account with password on 
the ESP workstation. This account will be limited to 
read/execute/delete access for ToJSSP, and write/execute 
access for FromJSSP. V 

ii. Interface Control File 

Each subdirectory has an Interface Control File. 

This is a file recording each copy from and copy to performed 
by either party. It is archived by the ESP workstation. 

Row Contents: "FromTTo", "SSPTESP", Date-Time Stamp, 
Filename, Record Count, Hash Total (to be 
defined, by file type) 

Filename: Control.txt 

b. To_SSP 

For either solution, this will contain the following data files, all in 
comma-delimited ASCII format. 




SSFb SytUm 
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i. Interface Control File 
II. ADV - Administrative Messages, Visa Format 

See page 30 for a description. 

Filename: ADV_999.txt, where 999 is a sequentially assigned 
number. 

///. Customer Data 
M SSP Customer Profile Table 

See page 39. 
Filename: Customer.txt 

i: v. Template Data 

q Template Index Table . 

See page 41 . This file is used by the SSP to check the 
^ Statement Template Number portion of the Statement Descriptor 

(see page 42). 

yi Filename: Template.txt 

c. From_SSP 

O i. Interface Control Total File 

y3 

^ H. ADV - Administrative Messages, Visa Format 

y i 

See page 30 for a description. 

Filename: ADV_999.txt, where 999 is a sequentially assigned 
number. 

ill. SAR - Statement Legacy Records, Augmented 

See page 41. 

Filename: SAR\<CSP ID>Xxt E.g.: 
F7wra_SSP\SAR\C1234567.txt 

2. ESP Statement Origination Workstation to ePay Switch to ESP 
Statement Generation Workstation 

This communication path will be implemented as a 
RAS PPP connection - either dial-up, packet- 
switched, or dedicated. Messages will be transferred j£; 
to and from a Microsoft Exchange Server running at 
the ePay Switch. 
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See Incremental Template Updating on page 19 for a complete description of 
the ESP System's use of Microsoft Exchange Server. 

3. ESP Template Authoring Workstation to the ESP Statement 
Origination Workstation 

This interface will consist entirely of new and 
updated Templates. It can be either a LAN link or 
"sneakernet" - the exchange of floppy diskettes. 



4. ESP Statement Generation Workstation to the CSP's Home 
Banking System 

Administration Messages, Visa Format (AD V), 
Fully Rendered Statement PDF Files (STM), 
Optional Detail PDF Files, and Optional Generic 
Enclosure PDF Files are passed between the ESP 
Statement Generation Workstation and the CSP's 
Home Banking System. 

Communication between the CSP and ESP will be in the form of a Local 
Area Network. The Windows NT software of the ESP Statement Generation 
Workstation can connect to most LANs in use today, including UNIX 
TCP/IP, IBM SNA, Novell Netware, Windows NetBEUI, Appletalk, DECnet, 
etc. 

a. Transport Mechanism 

Data. is passed in ASCII files stored in two subdirectories (TojCSP 
and FromjCSP), or in subdirectories below them. Once copied, files 
are deleted by the recipient. 

i. Security 

The CSP will need a Windows NT account with password on 
the ESP workstation. This account will be limited to 
read/execute/delete access for To_CSP t and write/execute 
access for FromjCSP. 

ii. Interface Control File 

Each subdirectory has an Interface Control File. 

. This is a file recording each copy from and copy to performed 
by either party. It is archived by the ESP workstation. 

Row Contents: "FromVTo", "CSPTESP", Date-Time Stamp, 
Filename, Record Count, Hash Total (to be 
defined, by file type) 



Vua'aBSP 
Statement 
ij^ Origination 
'Workstation 



Visa's ESP 
Template 
Authoring 
J] Workstation 



u 

0 



STM, 
OFT, 
. ADV 



CSP't Visa's Statement 

Home Banking Generation 
System Workstation 
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Filename: Control.txt 
To_CSP 

This will contain the following data files, all in comma-delimited 
ASCII format. 

I. Interface Control Total File 

II- ADV - Administrative Messages, Visa Format 

See page 30 for a description. 
In addition, the following files will be placed in a Template 
subdirectory, named for the Template Number (Template ID without 
Version Number): 

HI. INF - Statement index 

In comma-delimited ASCII format. See page 44 for a 
description. 

iv. The Statement Descriptor 

v. This ASCH text contains all data necessary to pay the 
Statement and to display it on Non-Conforming 
Devices. 

See page 4240 for a definition of the Statement Descriptor, 
*h The Fully Rendered Statement PDF File 

One of these per Customer: for a large CSP there will be 
thousands of these for each Template. 

Since these are highly date specific, if Statement Batches 
Solution is used (see page 72), purging functions will have to 
be supplied by the CSP. 

Filenames for these PDF Files are provided in the Statement 
Index. 

See page 13 for a description. 

vii. Optional Details Index File 

In comma-delimited ASCII format. 

viii. Optional Details PDF Files 

Ix. Optional Enclosure Index File 

In comma-delimited ASCII format. 
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x. Optional Enclosure PDF Files 
From_CSP 

This will contain the following data files, all in comma-delimited 
ASCII format. 

i. Interface Control Total File 

ii. ADV - Administrative Messages, Visa Format 

See page 30 for a description. 



yy 



O 
y3 
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ESP Test Mode - Template 
Certification 

When certifying a new Statement Template, a SSP will want to test the results before 
releasing it to production. 

1- Step 1: Enter Test Data 

C Testing begins with entering test data into the data tables contained within 

yj ^ e Template. This data is used to generate test Statements at the ESP 

"1 Template Authoring Workstation, 

6 2. Step 2: Place New Template into Test Service 

oi 

p Once these meet the SSP*s requirements, the Template is placed into Test 

p Service by uploading it to the ePay Switch via the Statement Template in 

fU Test Service Req ADV. 

tB 

O 3. Step 3: SSP Opens a Test Customer Account with CSP 

The SSP opens a Customer account with a representative sample of CSPs. 

When this Test Customer requests ESP Service for a Statement, the 
N associated Customer Statement Delivery Request ADV is answered by a 

U Customer Statement Test Delivery Acknowledgment ADV. This sets the Test 

U Account Flag in both the SSP and CSP Customer Profile Tables (see page 

3 u }, ^ nd S enerates a "Dummy" Statement Content Record transmission to 
y3 the CSP > th e test data entered into the Template. If data has been 

Cm entered for more than one month* then Statement Content Records will be 

transmitted for each .month available. 

Statement ContenfRecords arriving at the ESP Statement Generation 
Workstation triggers the generation of a Fully Rendered Statement PDF File 
using the test data. 

Viewing these Statements via the CSFs Home Banking Software, in exactly 
the same way that the Customer will, will give the SSP complete confidence 
in their Template before placing it in production. 

4. Safeguards 

In order to safeguard against mishaps, Templates placed into Test Service 
- (ref: Template Data 

Template Index Table on page 41) cannot generate Statements for non-test 
Customers (ref: CSP Customer Profile Table on page 40), nor can they be 
used to parse Statement Legacy Records from the SSP (ref: SSP Customer 
Profile Table on page 39). 
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Future Considerations 

None of the following items will prevent the Pilot from going forward. Some of them will 
need to be addressed before General Release. 

1 . Downloading unchanging Statement elements to the 
Customer's PC is Inefficient 

Caching Statement elements on the Customer's PC is tricky because 

• many different configurations of PC's are possible 

• il is the property of the Customer, and requiring that files be 
^ stored there may be a political issue 

2 In addition, new Adobe technology has greatly improved downloading of 

31 PDF Piles, as follows: 

■g • all text and graphics are stored within the PDF Pile in Zipped 

=T= format 

g • repeating bitmaps are detected and included only once 

*f • WWW bit-serving technology is used to display the PDF file as it 

is downloaded - the Customer does not have to wait until the 
y " ; whole file is downloaded before viewing it. 

£ 2. Manipulation of Adobe Interactive Elements from within the 

Template 

Currently, manipulation of Adobe Interactive Elements within the The 
^ Interactive Page (see page 12) is restricted to FDF files generated by the 

U s FDF Writing Module (see page 16) within the Template. 

Direct manipulation of Adobe Interacti ve Elements on the Access Report 
would be a major benefit. This would allow, for example, a Web link to be 
placed over telephone numbers on a telephone bill, so that the Customer 
could find out who they had called. 

3. Too Many Fonts 

The performance of Windows workstations degrade when too many fonts are 
installed (over 500). 

Font management software may be needed for post-pilot implementation. 

4. Generation of Fully Rendered Statement PDF Files for Non- 
conforming Device Customers 

Generation of Fully Rendered Statement PDF Files for Non-conforming 
Device Customers is a waste of processing, since Non-conforming Devices ■ 
cannot display Fully Rendered Statement PDF Files. 

Avoiding this is deferred to post-pilot implementation. 
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5. System Certification: Installation at New Sites, and System 
Upgrades 

Once the ESP System enters production, newly added SSP or CSP sites will 
have to be tested before they can join the system with any degree of safety. 
In addition, modifications to the ESP software, and installation of new 
versions of system software or hardware will have to be tested before they 
can join the system. 

This can be performed by a complete "test" system: a second ePay Switch, 
communications system and workstations. The Statement Origination 
Workstations will be designed to have a representative "test" Statement 
Content Record Stream to send upon command to a number of Statement 
Generation Workstations, 

This system needs to have only a small inaction of the capacity of the 
production system, yet its value in certifying new sites, software and 
hardware will be invaluable, especially in a high-reliability environment like 
ESP. 

6. Determine OLE Servers to be made available to Statement 
Originators 

OLE objects, such as graphs, drawings, etc., can be imbedded into Template 
reports. Use of such objects requires that the associated OLE Server (a 
program such as Microsoft Excel, CorelDRAW, etc.) be installed, in the 
correct version, at ALL ESP Statement Generation Workstations. 

This is a licensing and management issue, not a technical one. 

7. Statement Service Providers with Multiple Sites 

Statement Service Providers with Multiple Sites will simply have a different 
SSP ID for each site. If a Statement Originator is delivering Statement 
Legacy Records to more than one Bite, they will require separate UBFBiller 
ID'b for each site. 

Since a Template can be for only UBFBiller ID, this means that the 
appropriate Templates will have to be duplicated. 

It would be much more elegant if this was handled by the system. 
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Appendix A - What's New ? 

The purpose of this section is to highlight differences between the architecture described in 
Versions 1.1 and 1.2 of this document. 

1. Name Changes 



: E 







Invoice 


Statement (may not require payment !!) 


Biller 


Statement Originator 


ESP BSP Workstation 


ESP Statement Origination Workstation 


Biller Service Provider 


Statement Service Provider 


BSP 


SSP 


Customer Service Provider (CSP) 


Customer Financial Institution or its 
Service Provider (CSP) 


Consumer 


Customer (may be a business) 


BSP Biller ID 


SSP Biller ID 


Biller Account Number 


CBAN 


Interactive Area 


Interactive Page 


Statement Index Record 


Statement Descriptor 


Billing Date 


Statement Cycle Date 



New Statement Structure 

The ESP System's market success will depend on satisfying both Customers 
and Statement Originators, Customers want to download only information of 
interest to them, and Originators do not want to annoy Customers with 
unwanted information. Accordingly, to encourage optional data and brevity 
in mandatory data, we have formalized the constituents of any statement, as . 
shown below. ' 



Statement Constituents 



i. interactive Page 

E.g. buttons to request optional documents, to access multi- 
media features, and to access Web-links 

ii. Mandatory Customer-Specific Pages 

E.g. bill summary 

iii. Mandatory Generic Enclosures 

E.g. regulatory enclosures 

iv. Optional Customer-Specific Pages 

E.g. bill detail 
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v. Optional Generic Enclosures 

E.g. promotions 

vi . Statement Descriptor Data 

E.g. summary data and pointers to PDF files. 

Statement Descriptor Data is the only one required. Note that 
current design provides explicitly for Optional Customer-Specific 
Pages, which, if present, will require generation of a second Access 
report. This second Access-generated PDF file would be created 
^ during the same OLE call to Access as the first. 

W b. Statement PDFs 

H A Statement is presented to the Customer in the following parts: 

O 

y s /. Fully Rendered Statement PDF File 

Q This file contains the Interactive Page (if present) and any 

fy mandatory portions of the statement. 

//- Optional Customer-Specific PDF File 

At most one of these exists per Statement E.g. Statement 
Detail. 



m 



Optional Generic Enclosure PDF Files 

Any number of these exist for a Statement. E.g. promotions. 

3. CSP Portion of Interactive Page Deleted 

Version 1.1 stated that each CSP would be responsible for authoring an 
Interactive Page of fixed size to be merged with the SSP's portion of the 
Interactive Page. The CSFs portion had been required to have a "Pay" 
button and a "List of Statements" button, and would likely have featured the 
CSP*s logo as well. The CSP would have used Acrobat Exchange to create 
this portion of the page, and would have used a custom ESP plug-in 
(nicknamed the "Inverse Distiller") to save it in PostScript/PDFMark format. 
CSPs would have been required to register this PostScript fragment with the 
ePay Switch. Visa personnel would have verified its dimensions and 
functionality before marking it suitable for commercial use. 

For the current design, this requirement has been deleted because we feel 
that the CSP's interactive functionality (Pay and List of Statement buttons) 
is better accomplished using the native format of the server. For Web- or 
Intranet-based servers, this format is HTML, whereas for proprietary 
software, this format is the language (e,g k C**) used to develop the software. 
In deleting this requirement, we put more control back into the hands of the 
CSP and also enable other simplifying changes to the generation process. 
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4. New Statement Authoring and Generation Procedures 

a. The Old Way 

The procedure for generating the Fully Rendered Statement PDF has 
been changed significantly. In Version 1.1, the Fully Rendered 
Statement PDF was generated by first creating CSP and SSP 
portions of the Interactive Page and saving them in 
PostScript/PDFMark format, using a custom plug-in to be installed 
with Acrobat Exchange at the ESP Template Authoring Workstation. 

These PostScript fragments were to be combined (by Adobe Distiller, 
which converts PostScript to PDF) with the Access-generated 
personalized statement that had previously been written to file in 
PostScript format. The Interactive Page was to have been created in . 
PDF format using Acrobat Exchange, converted to PostScript using 
the Inverse Distiller Custom Plug-In, and then merged with the 
Access output and converted back to PDF using Distiller. This 
circuitous procedure was needed to tightly stitch the Interactive Page 
to the Access page and to merge the CSP portion of the Interactive 
Page with the SSP^s portion. 

b. The New Way 

By dropping the need to stitch the Interactive Page to the first page 
of the Access report, and by dropping the noed for a CSP portion of 
the interactive page, we have simplified authoring and generation 
considerably. 

In the current design, the Interactive Page is created entirely by the 
Statement Originator as a forms-based Acrobat 3.0 document, and is 
saved as a Template resource. 

During Statement Generations FDF File may be created which is 
later used by Adobe Exchange to customize the Interactive Page. 

The Access report is written out directly in PDF format using 
Adobe/s PDFWriter device driver rather than being written first to 
PostScript and then later converted to PDF format by Adobe 
Distiller. 

Finally, the merge of the Interactive Page PDF, the Mandatory 
Customer-Specific PDF pages, and any Mandatory Generic Enclosure 
PDFs is accomplished using Acrobat Exchange, called as an OLE 
server to the main Visual Basic software. 

The current design avoids the need to develop and maintain (in C) 
the Inverse Distiller custom Acrobat plug-in, the need to write 
custom code to accomplish the PostScript merge, the need to use 
Distiller, and the need to register and validate the CSP Interactive 
Area. 

5. Incremental Template Updating 

To minimize data flow, Templates will be updated rather than replaced - that 
is ( only items that change will be transported through the system. 
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However, this capability may be deferred until after the Pilot. 
See Incremental Template Updating on page 19. 

6. Statement Content Record Transportation 

In both Version 1.1 and 1.2, Statement Content Records are to be transported 
as attachments to Microsoft Exchange (not to be confused with Adobe 
Exchange !) mail messages. 

Version 1.1 was based on sending in each mail message a single attachment 
containing a comma-delimited representation of just those records (from one 
or more tables) needed to generate a single Statement, This approach has 
the advantage that a corrupted transmission affects only one Statement In 
the current design, each mail message will contain all the data needed to 
create a batch of Statement (e.g.: 500 or 6,000) in the form of separate 
attachments, one for each required table. 

• By keeping data from different tables in separate attachments, 
we avoid the processing time required for assembly and for 
disassembly. 

• By grouping a batch of statements together in one mail message, 
we improve the efficiency of SQL Server table updating. 

• To the extent that batches are kept small, we can minimize the 
impact of corrupted transmissions. 

The current design provides the ability to optimize the batch size by trading 
off the adverse impact of data corruption against the adverse impact of 
excessive processing to bundle and unbundle data. 

7. Distribution of Standard Statement Rendering Too! 

In response to expressions of interest from SSPs, the The Standard 
Statement Rendering Tool (see page 49), will be made available to both CSPs 
and SSPs themselves, not just to VisaM* workstations on their premises. 
SSPs and CSPs may wish to provide this tool to their Customer Service 
Departments. 

8. Switch Design 

To augment security and level telecommunications loading at the ePay 
Switch, we now plan to poll (call out to) all Workstations from the ePay 
Switch. 

In the event that CSPs or SSPs are unwilling to transfer data via incoming 
calls, we may institute call-back procedures wherein CSPs and SSPs call the 
ePay Switch whenever they receive any incoming call. 

Normally, the calls coming to CSPs and SSPs would be from the ePay Switch 
advising its desire to communicate. Authentication codes could be devised for 
the originating and the call-back calls that would discourage hacking. 
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9. Administrative Messages 

a. Generation Failure 

We have added an urgent message in the event of Statement 
generation failure. 

b. Statement Originator Splits and Mergers 



Statement Originator initiated account number changes, for 
whatever reason, will require a new Administrative Message from 
SSPs to CSPs. 




Dates are also needed for integrity in the event that Statement 
Originators re-assign account numbers to different customers using 
the same CSP t e.g. reassign telephone numbers. 



10. Mail Robots. 

In Version 1.1, an asymmetry in the mail delivery process arose because the 
CSP could only address Statement Originators and not their SSPs (to whom 
their mail must first be delivered). 

This was because the system had been designed such that CSPs do not know 
Statement Originator's SSPs. The consequence was that we needed a mail 
robot at the ePay Switch to log on as each Statement Originator and move 
that Statement Originator's incoming mail to the outbox of its SSP. 

For the current design, we are proposing to allow CSPs access to selected 
fields of the UBF which will allow them to address mail directly to a 
Statement Originator's SSPs. This eliminates the need for one mail robot 
process at the ePay Switch. 

1 1 . Universal Bilier File (UBF) 

Two new fields have been added to the UBF, one 16-byte field for an ID, and 
one 24-byte field intended for ESP flags. 

See UBF- Universal Bilier File on page 28 for a complete description. 

12. CSP Account Number 

CSPs will now be able to pass an identification field with each Customer 
Statement Delivery Request ADV that can be used to identify its Customers. 

This key will enable the Statement Generation Workstation to respond to 
queries for all Statements available for a given CSP Account Number. 

Note that use of this identification number is optional, and that the number 
if given need not correspond to the actual customer number used by the CSP 
to identify its Customer. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Pageg9 . gSP System Architecture 



See CSP Customer Profile Table on page 40. 

1 3. Statement Download Log & CSP Pull Procedures 

bv^f rqp 17 ^.f.^f^n * h *" one of their Statements is Pulled 
by the CSP and when it is Pushed to the Customer. 

See Statement Download Log on page 44. 

14. Summary Types 

Statements will be of a designated type, and Statement Descriptor^ page 
^ 42) will vary accordingly. e 

ff% 

-TJ ^l 8 wiH ™! ude ■* ^ o^et: invoices, statements, and advisories. 

Invoices are tells and are characterized by being payable. 

15. ESP Customer Activation 

The option of having the Statement Origination Workstation respond 
positively or negatively to activation requests on behalf of the Statement 
Originator has been dropped for lack of interest Instead, the Workstation 
will pass activation requests directly to the Statement Service Providers 
system who will respond on the Statement Originator's behalf or pass it 
directly to the Statement Originator. 

16. Payment Issues 

The capability to split payments among multiple accounts with the same 
payee will be deferred until after pilot. 

1 7. Multi-Site SSP Operations 

SSPs who must generate statements for the same Statement Originator from 
multiple S1 tes each with its own SSP W, will have to handle passing 
l emplateB and mail messages among these sites internally We will 
continue view each Statement Originator as having a unique SSP endpoint. 

18. Security 

Although we may defer use of Exchange-based encryption and digital 
signatures on top of NT security duringpilot to speed development, we 
continue to intend to implement this capability for commercial operations 
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Appendix B- What it takes to be an 
ESP Statement Service Provider 
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To set up operations as an ESP Statement Service Provider for the ESP Pilot will require 
the following: 

• Hosting of ESP hardware 

• Communication with the ESP hardware 

• Communication with Visa's ePay Switch 

• Modification to your current data processing system 

• Development of Statement Templates, in the form of Microsoft Access Reports 

A. Hosting of ESP Hardware 

Visa's ESP Statement Origination Workstation will be installed at your site. For purposes 
of the ESP Pilot, this will be a single Intel-based box running Windows NT Workstation. 
For production volumes, this may be upgraded to Windows NT Server, and several more 
Intel and non-Intel (e.g. : DEC Alpha) CPUs may be added. 

During the ESP Pilot, this equipment will be developed, installed, and maintained by Visa, 
It will be operated by the SSP f and its reports will be monitored by the SSP. 

B. Communication with the ESP Hardware 

The SSP's System connects with the ESP Statement Origination Workstation via LAN. 

The Windows NT software of the ESP Statement Origination Workstation can connect to 
most LANs in use today, including UNIX TCP/IP, IBM SNA, Novell Netware, Windows 
NetBEUI, Appletalk, DECnet, etc. 

Communication is via copying ASCII files over the LAN to and from Network Shares 
provided by the ESP Statement Origination Workstation. 

C. Communication with Visa's ePay Switch 

Communication from the ESP Statement Origination Workstation to Visa's ePay Switch will 
be required. The bandwidth necessary will depend completely upon the volume of 
Statements involved in the Pilot. 

This will be supplied by the SSP to Visa's specifications. For purposes of the Pilot, a pair of 
telephone lines or a single IDSN line will be ample. 

D. Modification to your Current Data Processing 
System 

For a complete description of the SSP's system's requirements, please see page 49. 
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The main print stream will be split into two streams: one for print and one for ESP, 
depending upon the Customer Profile Table. Some Customer's data will go to one or the 
other and some will go to both. 

The ESP stream will be modified into the format of Statement Legacy Records, Augmented 
(see page 41). 

The SSP will have to receive and process Administrative Messages (ADV - see page 28) and 
generate responses and return them to the ESP Statement Origination Workstation. See 
page 49 for a complete description of this process. 

E. Development of Statement Templates, in the form 
of Microsoft Access Reports 



1. Statement Templates 

2 TPL - The Statement Templates are described on page 15. 

One of these will be required for each different Statement type that will be 

^ processed by ESP. In addition, each month that a change is made to a 

ST: Statement, the Template must be updated. 

|j 2. The level of Access expertise needed 

Jt; The ley el of Access expertise needed to generate a Template depends upon 

y 1 the level of sophistication of the Statement. 

^ Desktop-publishing staff should be proficient at developing simple Templates 

O with a f ew hour's training. Complex Templates will require the efforts of 

^ both the desktop-publishing staff and an Access consultant. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 92 



ESP System Architecture 



Appendix C- What it takes to be an 
ESP Customer Financial 
Institution/Service Provider 

To set up operations as an ESP Customer Financial Institution /Service Provider for the 
ESP Pilot will require the following: 

• Hosting of ESP hardware 

• Communication with the ESP hardware 

• Communication with Visa's ePay Switch 

• Modification to your current data processing system 

A. Hosting of ESP Hardware 

Visa's ESP Statement Generation Workstation will be installed at your site. It is an Intel- 
based Windows NT system with a LAN connection to your Home Banking System, and a 
communication link to Visa's ePay Switch, 

For purposes of the ESP Pilot, this will be a single Intel-based box running Windows NT 
Workstation. For production volumes, this may be upgraded to Windows NT Server, and 
several more Intel and non-Intel (e.g.: DEC Alpha) CPU's may be added. 

During the ESP Pilot, this equipment will be developed, installed, and maintained by Visa. 
It will be operated by the CSP, and its reports will be monitored by the CSP. 

B. Communication with the ESP Hardware 

A LAN connection with the ESP Statement Generation Workstation will be required. The 
Windows NT software of the ESP Statement Generation Workstation can connect to most 
LANs in use today, including UNIX TCP/IP, IBM SNA, Novell Netware, Windows NetBEUI, 
Appletalk, DECnet, etc. 

C. Communication with Visa's ePay Switch 

Communication from the ESP Statement Generation Workstation to Visa's ePay Switch will 
be required. The bandwidth necessary will depend completely upon the volume of 
Statements involved in the Pilot. 

This will be supplied by the SSP to Visa's specifications. For purposes of the Pilot, a pair of 
telephone lines or a single IDSN line will be ample. 

D. Modification to your Current DP System 

Three major new functions must be added: ESP Sign-up, Statement and Optional Enclosure 
display, and Statement Payment. 

For a description of the data that must be stored and the processes that must be supported, 
see page 71. 
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Appendix D- A Sample Statement 
using Microsoft Access® Reports 

A. Introduction 

An sample Statement was generated using Microsoft Access® v7.0. The following elements 
are included: 

1. A photocopy of the original Statement 

2. Adobe Acrobat (PDF) version of the Statement, 

3. Statement Augmented Records (SAR) 

4. The Statement Template, including Statement Stationary, parsing tables, and 
reports 

5. Statement Content Records and Tables 

6. Files, with their sizes in compressed and uncompressed form, as generated by 
this example 

B. A Photocopy of the Original Statement 

Figure 11 - A Photocopy of the Original Statement 

C. Adobe Acrobat (PDF) version of the Statement 

Two Statements are generated, one for a Customer with Paid = True, and one, with Paid = 
False. 
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Figure 12 - A Statement with Paid = False 
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Figure 13 - A Statement with Paid - True 
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D. Statement Augmented Records {SAR) 



These SAR Records are in Fixed-Length format. They could also be in SQL-Table, Print- 
Image, or Comma-Delimited form. 

Note that Record type "0000" is the Statement Content Header, UBFBiller ID (BIN) = 
123456789012, and Template ID Number = T0000001. Holding is used to show separate 
fields. 

; 1 ; 2 ; 3 ; 4 ; 5 ; 6 ; 7 ; . 

.8 

000000000000 123456789012T0000001 

100400000000101222222306/06/96 
1004 00010 OOOSuzio Q Public 
100400020000123 Somewhere Ave, #999 
100400030000Thls in the Place 
1004OOO40000San Elsewhere, CA 99999 
10040005000006/21/960000432. 10B00 678-8796444 555-12,12 
100400060000San Elsewhere Showroom 
100400070000False 

11130001000106/01/9601000000. 00 

1113OOO10OO2Rental- 9 Items, 06/01/96 to 07/01/96 
11130002 000106/01/9602100004.90 

I111300020002BED FRAME- KINO, QUEEN 
11130003000106/01/96031000017 .20 
1113OOO30002BLUE DAMASK QUEEN MATTRESS 
11130004000106/01/96041000013 .40 
1113 000400 02 BLUE DAMASK QUEEN BOX SPRING 
11130005000106/01/9605200007.02 
1113 0005 00 02FROLIC CHAIR 
11130006000106/01/9606200009.60 
111300060002TARRAGANO NITE STAND 
11130007000106/01/96071000013 .50 
1113OOO70002BERLIN IVORY DINING TABLE 
11130008000106/01/9608100005.95 
111300080002LAMP- ALMOND 
11130009000106/01/96090000095.25 
111300090002Damage Protection00007 . 0600095 .25 
11130010000106/01/96010 

111300100002Dietribution feeOOOOO . 0000040. 00 

100400000000239355758206/06/96 
100400010000 John J Jones 
100400020000324 This St, #567 
1004000300000ver There, CA 94402 
100400040000 

10040005000006/21/960000135.25800 678-8796444 555-1212 

1 004000600 OOFos'ter City Showroom 

100400070000True 

11130001000106/01/9601000000.00 

1113000l0002Rental- . 9 items, 06/01/96 to 07/01/96 

11130002000106/01/9602100004.90 

1113 0002 00 02 BED FRAME- KINO, QUEEN 

11130003000106/01/96031000017.20 

111300030002BLUE DAMASK QUEEN MATTRESS 

11130004000106/01/96041000013 .40 

1113 0004 00 02 BLUE DAMASK QUEEN BOXSPRINO 

11130005000106/01/9605200007.02 
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111300050002FROLIC CHAIR 
- 11130006000106/01/9606300009.60 
I 1113O0060002TARRAGANO KITE STAND 
11130007000106/01/96071000013.50 
111300070002BERLIN IVORY DINING TABLE 
11130008000106/01/9608100005.95 
111300080002LAMP- ALMOND 
11130009000106/01/96090000095.25 
11 13 000900 02Damage Protection00007 . 0600095 .25 
1113 0010000106/01/96010 

| 11130 0100 002DiBtribution feeOOOOO . 0000040. 00 



Figure 14 - Statement Augmented Records (SAR) 

E. The Statement Template 

The Statement Template consists of the following parts: 

• The Access Tables 

• The Access Reports 

• Statement "Stationary" Bitmap 

• SAR/Transport Mapping 

It also contains the Standard Class Module, as described in Appendix E - The Statement 
Template Access Class Module on page 103. 
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1 . The Access Tables 



a. SAR Fixed Length Parsing Tabie 









Slightly different formats would 


be used for other SAR Types. 




«* 


Table 




:Jj»J?PS. 






.VIM 

Ofifoet 

S : :': : : : ?S-" : M'?)^-7! : ?: 




Weld 




i 

X 




UBFBillerlD 


text 


00000000000 


13 


12 




o 




TemplateJD 


text 


00000000000 
u 


25 


7 


c 


3 




CBAN 


text 


10040000000 
n 

V 


13 


10 


ifi 


>t 
*• 




Statement_Cycle_Date 


date 


10040000000 

o 


23 


8 




5 




Customer_Name 


text 


10040001000 


13 


0 


m 


a 




Cu8tomer_Address_l 


text 


10040002000 
0 


13 


0 




7 




Customer ^Address_2 


text 


10040003000 

0 


13 


0 


m 


Q 

o 




Customer_Address_3 


text 


10040004000 

0 


13 


0 


yGi 


g 




Due_Date 


date 


10040005000 

0 


13 


8 




10 




AmountJDue 


currency 


10040005000 

o 


21 


10 




11 




Questions_Phone 


text . 


10040005000 
0 


31 


13 


3 : 


19 




Other_Phone 


text 


10040005000 
0 


44 


13 




13 




Location 


text 


10040006000 
0 


13 


0 




14 




Paid 


Boolean 


10040007000 
0 


13 


5 




15 


Items 


Item_Date 


date 


1113????000 
1 


13 


8 




16 


Items 


Order / 


integer 


1113????000 
1 


21 


2 




17 


Items 


Quantity 


integer 


1113????000 
1 


23 


1 




18 


Items 


Monthly Jtate 


currency 


1113????000 
1 


24 


8 




19 


Items 


Cost 


currency 


1113/????000 
1 


32 


8 




20 


Items 


Description 


text 


1113????000 
2 


13 


0 



Figure 15 - SAR Fixed Length Parsing Table 



b. Statement Resource Table 



: i~i^^^c0 Type " 




FileNain** 

^^^^^^^^^^^ 




Font 


Century Schoolbook 


Schblk.ttf 


font file 


Bitmap 


Statement Stationary 


T0000001.bmp 


bitmap of 

Statement Stationary 
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Figure 16 - Statement Resource Table 



FURNITURE RENTAL, INC. 
HOME & OFFICE 
P.O. BOX 100515 PASADENA, CA 911894515 



[H 



FOR CHANGE OF ADDRESS INDICATE HEREO AND SEE REVERSE SIDE, 
Pt£AK DCTACH AND HAL WTTH YOUR FAYWEKT; F PAYWO IN PERSON. BRINO STATEMENT. 



I 



BILLING QUESTIONS? CALL 
FOR OTHER QUESTIONS, GALL: 
SEE BACK FOR IMPORTANT 




Figure 17 - Statement "Stationary" Bitmap 
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T0000001 








Account_Number 


1012222223 


2393557582 


Statement_Cycle_Dat 
e 


06/06/96 


06/06/96 


Customer Name 


Suzie Q Public 


John J Jones 


Customer_Address 1 


123 Somewhere Ave. #999 


324 This St #567 


Customer_Address 2 


This is the Place 


Over There, CA 94402 


Customer_Address 3 


San Elsewhere. CA 99999 




Due_Date 


06/21/96 


06/01/96 


Amount_Due 


$432.10 


$135.25 


Questions_Phone 


800 678-8796 


800 678-8796 


Other_Phone 


444 555-1212 


415 573-5120 


Location 


San Elsewhere Showroom 


Foster City Showroom 


Paid 


False 


True 1 



Figure 18 - Primary Data Records 



d. T0000001 Items 



| Account 
i Number 


Statame 
fat Date 


Item 
Date 


0 




m- 


Bate 


.Cost 


i 1012222223 


06/06/96 


06/0y96 


1 


0 


Rental- 9 items, 06/01/96 to 07/01/96 


$0.00 


$0.00 


| 10122^223 


06/06/96 


06/01/96 


2 


l 


BED FRAMED KING, QUEEN 


$4.90* 




j 1012222223 


06/06/96 


06/01/96 


3 


l 


BLUE DAMASK QUEEN MATTRESS 


$17.20 




1 1012222223 


06/06/96 


06/01/96 


4 


l 


BLUE DAMASK QUEEN BOXSPRING 


$13.40 i 




; 1012222223 


06/06/96 


[ 6 ^01/9 6 


5 


2 


[ FTOlSccfiiS 


„ $776*2"] 




f 1012222223 


06/06/96 


06/01/96 


6 


2 


tarragan'6 Site stand 


$9.60 




i 1012222223 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING TABLE 


$13.50 




i 1012222223 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




[ 1012222223 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


1012222223 


06/06/96 


06/01/96 


10 


0 


Distribution fee 


$6.00 


$40.66 


2393557582 


06/06/96 


06/01/96 


1 


0 


Rental- 9 items, 06/01/96 to 07/0 1/96 


$0.00 


$0.00 


2393557582 


06/06/96 


. 06/01/96 


2 


1 


f BED FRAME- KING, QUEEN 


$4.90 i 




2393557582 


06/06/96 ' 


06/01/96 


3 


i" 


BLI^ DAMASK QUEEN MATOESS . 


$17.20 * 




2393557582 


06/06/96 1 


06/01/96 


4 


i 


BLUE 'DAMASK QUEEN BOi&PRING * 


$13740 1 




2393557582 


06/06/96 


06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




2393557582 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE STAND 


$9.60 




2393557582 


06/06/96 


06/01/96 


7 


1 j 


BERLIN IVORY -DlSmO TABLE 


$13.50 i 




2393557582 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




2393557582 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


2393557582 


06/06/96 A 


06/01/96 


10 


0 


Distribution fee 


$0.00 


$40.00 



Figure 19 - f Ttem" Data Records 



2. The Access Reports 

Two Access Reports are use: T0000001, and TOOOOOOlJtems. The second is included as a 
SubReport of the first, linked by Account Number and Statement Cycle Date. 

The Statement Stationary Bitmap is included as a Picture of the Report - i.e.: as a 
"Watermark". Converting this to a data-only report with the Stationary in a second PDF 
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file simply consists of deleting the Picture. This can be done from logic within the Report, 
triggered by, say, a global value in the Registry, set during system installation. 

The "Paid in Full" notice is an OLE Link to a Microsoft WordArt v2.0 object, called 
Paid_in_Full. The On Format event for the detail lines says: 

Figure 20 - Code to control Paidjn Jitll 

In other words, we only see the WordArt object if Paid = True. 

F. Statement Content Records 

1. The Records 

Statement Content Records are transmitted in comma-delimited form. Records for all 
Statements for a single CSP and Statement Template are batched together into a single mail 
message. The message is addressed as to the CSP ID, from the SSP ID. 

















g^^p|C1 234567 jf 


MSflmP ESP ArcWve * SendwArchive J|| 


S&S^i*™ « 987595333 - Statement COrient Rccadi ■ H«h 233111958 ~f§ 


T 0000001 vCOOCtxt TOOOOOOIvOOlO Itemt 
W 


% 

$ 

I 


Template TU000001V0014 

T0000001VTOOO.txt has 2 records - ' 
T0000001VDOOO_ltems.txt has 20 records 


1 

li 

i 





Figure 21 - The SAR E-Mail 



2. Records for this Statement 



"1012222223",6/6/96 0:00:00,"Suzie Q Public'7'123 Somewhere Ave, #999" l "This is the 
Place*\ M San Elsewhere, CA 99999",6/21/96 0:0O:00,$432.10/'80O 678-8796","444 555- 
1212'V'San Elsewhere Showroom".$0.00.0 

"2393557582",6/6/96 0:00:00,"John J Jones", ,, 324 This St, #567","Over There, CA 
94402"„6/l/96 OtfOtfO.JlSS^S/'SOO 678-8796", ,, 415 573-5 1207'Foster City 
Showroom",$0.00.1 

Figure 22 - T0000001VOOOO.txt 



"1012222223",6/6/96 0:00:00,6/1/96 0:00:00,l,0, M Rental- 9 items, 06/01/96 to 
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07/01/96".$0.00.$0.00 __ 

,, 1012222223".6/6/96 0:00:00.6/1/96 0:00:00,2, l."BED FRAME- KING. QUEEN",$4.90. 

"1012222223 ,, J 6/6/96 0:00:00,6/1/96 0:00:00,3, l/'BLUE DAMASK QUEEN 
MATTRESS M .$17.20, 

"1012222223 M ,6/6/96 0:00:00,6/1/96 0:00:00,4, 1,"BLUE DAMASK QUEEN 
BOXSPRING".$13.40. 

"1012222223".6/6/96 0:00:00,6/1/96 0:00:00.5.2."PROLIC CHAIR".$7.02. 

"1012222223",6/6/96 0:00:00.6/1/96 0:00:00,6.2. ,, TARRAGANO NITE STAND".$9.60. 

"1012222223".6/6/96 0:00:00.6/1/96 0:00:00.7, l."BERLIN IVORY DINING TABLE".$ 13.50. 

"1012222223",6/6/96 0:00:00.6/1/96 0:00:00.8, 1,"LAMP- ALMOND n ,$5.95. 

"1012222223",6/6/96 0:00:00.6/1/96 0:00:00.9,0,"Damage Protection".$7. 06.S95.25 

"1012222223".6/6/96 0:00:00,6^96 0:00:00, 10,0."Distribution fee",$0.00.$40.00 

n 2393557582",6/6/96 0:00:00,6/1/96 0:00:00,1,0, "Rental- 9 items, 06/01/96 to 
07/01/96",$0.00.$0.00 

"2393557582 ,, ,6/6/96 0:00:00,6/1/96 0:00:00,2, l."BED FRAME- KING. QUEEN".$4.90. 

' , 2393557582",6/6/96 0:00:00,6/1/96 0:00:00,3, l/'BLUE DAMASK QUEEN 

MATTRESS",$ 17.20. . 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00,4, 1,"BLUE DAMASK QUEEN 
BOXSPRING , ',$13.40. ■ 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00,5,2."FROLIC CHAIR".$7.02. • 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00.6.2. ,t TARRAGANO NITE STAND",$9,60. 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00,7, l/'BERLIN IVORY DINING TABLE".$ 13.50. 

"2393557582",6/6/96 0:00:00,6/V96 0:00:00,8. l."LAMP- ALMOND".$5.95. 

M 2393557582 M ,6/6/96 0:00:00,6/1/96 0:00:00,9,0,"Damage Protection".$7.06.$95.25 

M 2393557582 ,, ,6V6/96 0:00:00,6/1/96 0:00:00. lO.O/'Distribution fee",$0.00 T $40.00 



Figure 23 - T0O0OOOlV0000Jtems.txt 

G. File Sizes. 





i'->^ : ^ Sise (totes) 


ISIiL ' "■ -. ■• 


T0000001.bmp 


671k 


- "Stationary" bitmap (not used) 


TOOOOOOlxdr 


35 k 


- "Stationary" bitmap - CorelDRAW! 


T0000001.mdb 


254 k 


- Access Database with reports & bitmap 


1 mdb.zip 


85 k 


- contains T00QOO01.MDB 


T0000001.pdf 


53 k 


- "Complete" PDF 


I PDF.zip 


53 k 


• contains T0000001.pdf- already compressed 



Figure 24 - File Sizes for the 'Brook" Statement 
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Appendix E - The Statement Template 
Access Class Module 

a^ts^^ anOLEAutcnationServe, It is 

Automation cZ^o llt^tn " ^ and Methods for OLE 



Statement_Cycle Date 



Methods 



ShowJStationary 



DataSource 



Connect_String 



Used to select records from Statement Content 
laples. 



ditto 



True or False. Hides or shows Statement 
Stationary", in the form of a "Picture" on the 
main Tfcmnw- ^ cad l 



Report or SubReport. 



"Test" or "Prod" 



Generate Report 



If DataJSource 
Connect 



= "Prod" then use 



.String to attach to ODBP n»f »K QCQ 



1/ 



21 



Set output to file <CBAN> PDF 
(e.g.: "(416)372-1492.PDF». Note that this 
assumes that the CBAN does not contain 
any characters that Microsoft Windows NT 
v4 0 considers illegal in filenames. This is 
subject to conformation). 

C&W ReP ° rt PaterS 10 8eleCt ° nly ***** 
Generate the Report. 



Figure 25 - Properties and Methods Common to ALL Statement Templates 
Other Properties and Methods will be added as needed. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 104 



ESP System Architecture 



Appendix F - Anatomy of the Access 
Examples 

Two example Statements are presented: the Brook Statement of Appendix Dand a Pacific 
Bell Statement. 



A. The Brook Invoice Template 




1. The Tables 

a. IAR_FixedJ-ength_Parsing_Table 



6 Data 


Tabte 
Name 




Type 


.Key likev:; 


QfFstit 




06/06/96 




UBFBillerlD 


text 


000000000000 


13 


12 


06/06/96 




TemplateJD 


text 


000000000000 


25 


7 


06/06/96 




Biller_Account_Number 


text 


100400000000 


13 


10 


06/06/96 




Invoice_Date 


date 


100400000000 


23 


8 


06/06/96 




Customer_Name 


text 


100400010000 


13 


0 


06/06/96 




Customer_Ads!ress_l 


text 


100400020000 


13 


0 


06/06/96 




Customer_Address_2 


text 


100400030000 


13 


0 


06/06/96 




Customer_Address_3 


text 


100400040000 


13 


0 


06/06/96 




Due_Date 


date 


100400050000 


13 


8 


06/06/96 




Amount_Due 


currency 


100400050000 


21 


10 


06/06/96 




Questions_Phone 


text 


100400050000 


31 


13 


06/06/96 




Other_Phone 


text 


100400050000 


44 


13 


06/06/96 




Location 


text 


100400060000 


13 


0 


06/06/96 




Paid 


boolean 


100400070000 


13 


5 


06/06/96 


Item 


Item_Date 


date 


1113????0001 


13 


8 


06/06/96 


Item 


Order 


integer 


1113????0001 


21 


2 


06/06/96 


Item 


Quantity 


integer 


1113????0001 


23 


■1 


06/06/96 


Item 


Monthly_Rate 


currency 


1113????0001 


24 


8 


06/06/96 


Item 


Cost 


currency 


1113????0001 


32 


8 


06/06/96 


Item 


Description 


text 


1113????0002 


13 


0 
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b. lnvoice_Resource_Tab!e 



mm 




Invoice 
Resource- 






06/06/96 


Font 


Century 
Schoolbook 


Schlbk.zip 


Binary Object 


06/06/96 


Bitmap 


Invoice 
Stationary 


cdr.zip 


Binary Object 



c. TOO 0000 1-v1 



i: 

i 




sU> 
ma ' 
r 

Na- 
m 


me* 

"Ml 


Caate 

nW 

A^drc 

■ ■ • 


mer • 
Addre 

- : - 

\ ' .*■■ T' 


Dim 
fiate 

■ 

iiilii! 

■ ■ 


Amott 
Bub 


Quest 

Ions ' 
Phone 

■■ 

mi 


■ 


Loeaitod 

liililll 

fillips 

iiilfiti 




■ 


10122 
22223 


06/06/96 


Suz 

ie 

Q 

Pu 

blic 


123 

Some 

where 

Ave, 

#999 


This 
is the 
Place 


San 

Elsew 

here, 

CA 

99999 


06/21/ 
96 


$432. 
10 


800 
678- 
8796 


444 
656- 
1212 


San 

Elsewhe 
re 

Showroo 
m 




$0.00 


0 


23935 
57682 


06/06/96 


Joh 
nJ 
Jon 
es 


324 
This 
St, 
#567 


Over 
There 
, CA 
94402 




06/01/ 
96 


$135. 
25 


800 
678- 
8796 


415 
673- 
6120 


Foster 
City 

Showroo 
m 


$0.00 


-1 



d. T0000001Jtems-v1 

o 



03 





Invoice 
Date 


ttem Date 


Order 


<** 




■p^^ptim 




Cost 


1012222223 


06/06/96 


06/01/96 


1 


0 


Rental- 9 items, 
06/01/96 to 07/01/96 


$0.00 


$0.00 


1012222223 


o&ome 


06/01/96 


2 


1 


BED FRAME- KING, 
QUEEN 


$4.90 




1012222223 


06/06/96 


06/01/96 


3 


i 


BLUE DAMASK QUEEN 
MATTRESS ♦ 


$17.20 




1012222223 


06/06/96 


06/01/96 


4 


i 


BLUE DAMASK QUEEN 
BOXSPRING 


$13.40 




1012222223 


06/06/96 


06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




1012222223 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE 
STAND 


$9.60 




1012222223 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING 
TABLE 


$13.50 




1012222223 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




1012222223 


06/06/96 


06/0y96 


9 


0 


Damage Protection 


$7.06 


$95.25 


1012222223 


06706/96 


06/01/96 


10 


0 


Distribution fee 


$0.00 


$40.00 


2393557582 


06/06/96 


06/01/96 


1 


0 


Rental- 9 items, 
06/01/96 to 07/01/96 


$0.00 


$0.00 


2393567582 


06/06/96 


06/01/96 


2 


1 


BED FRAME- KING, 
QUEEN 


$4.90 




2393557582 


06/06/96 


06/01/96 


3 


1 


BLUE DAMASK QUEEN 
MATTRESS 


$17.20 




2393557582 


06/06/96 


06/01/96 


4 


1 


BLUE DAMASK QUEEN 
BOXSPRING 


$13.40 
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2393557582 


06/06/96 


06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




2393657582 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE 
STAND 


$9.60 




2393657582 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING 
TABLE 


$13.60 




2393557582 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




2393557582 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


2393557582 


06/06/96 


06/01/96 


10 


0 




$0.00 


$40.00 



2. The Reports 
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a. TOO 0000 1-v1 




Fnvate Sub DetaiI_Format(Cancel As Integer, FormatCount As Integer) 

Me!PaidJn_Full.Visible = (MelPaid) 
End Sub 
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TOOOOOOl-vl's ReportPicture is a CorelDRAW! * cdr file containing a raster representation 
of the Brook Invoice's Stationary. It is VERY much smaller than the bitmap (38k vs 600k). 

b. T0O0O0O1_ltem-v1 



1 


[item Datij 








ityj {Description 


_ ijiiontliiy S j 


Cost 













Note that all of these fields have .Top=0, and that they are spread out for clarity only. 

B. The Pac-Bell Invoice 




1. The Tables 



a. T0000002-V1 







Account Number 


415 343-8441 764 N 7 159 


Statement Date 


06/02/96 


Customer Name 


John Q Public 


Customer Address 1 


1234 SOME STREET 


Customer Address 2 


APT 87667 


Customer Address 3 


SAN SERIEF CA 


Customer Address 4 


94402-9999 


Due Date 


06726/96 


Late Date 


07/05/96 


Total Due 


$27.82 


Total Pacific Bell Monthly Charees 


$16.24 


Total Add n Chancres to Service 


$11.58 



b. T0000002_Current_Charges-v1 





umber 


.5^afceiue0t . 


^i^£%J Description 














j Amount 
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415 343-8441 764 N 7 
159 


06/02/96 


1 


Pacific Bell 


2 


$27.82 


0 


415 343-8441 764 N 7 
169 


06/02/96 


2 




0 


$27.82 


-1 



c. T0000002Jnstallments-v1 

This table is empty 

d. T0000002 Monthiv Charae 





! l-Staterae 


Ite 




line 
# 






■ 


One/ 
TSnte 


• J&tnfc 


h 

i mm 


415 
343- 
8441 
764 N 
7159 


06/02/96 


1 


Basic 


l 


Residence 
Service 
Flat Rate 


i 






$11.25 


0 


415 
343- 
8441 
764 N 
7159 


06/02/96 


2 


Basic 


0 


Monthly 
Service 
Jun 2, 
1996 thru 
Jull, 
1996 


0 






$11.25 


-1 


415 
343- 
8441 
764 N 
7159 


06/02/96 


3 


Taxes 


2 


Charges 
for 

Network 

Access for 

Interstate 

Calling, 

Imposed 

by 

Federal 

Communi 

cations 

Cimmissi 

on 


0 






$3.50 


0 


415 
343- 
8441 
764 N 
7159 


06/02/96 


4 


Taxes 


3 


California 
High Cost 
Fund 
Surcharg 
e 


0 






$0.12 


0 


415 
343- 
8441 
764 N 
7159 


06/02/96 


5 


Taxes 


4 


Universal 

Lifeline 

Telephon 

e Service 

Surcharg 

e 


0 






$1.44 v - 


0 


415 


06/02/96 


6 


Taxes 


5 


Rate 


0 






($0.82) 
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343- 
8441 
764 N 
7159 










Surcharg 
e 












415 
343- 
8441 
764 N 
7 159 


06/02/96 


7 


Taxes 


6 


State 
Regulator 
y Fee 


0 






$0.05 


0 


415 
343- 
8441 
764 N 
7 159 


06/02/96 


8 


Taxes 


7 


CA Relay 

Service 

and 

Comunica 
tions 
Devices 
Fund 


0 






$0.17 


0 


415 
343- 
8441 
764 N 
7159 


06/02/96 


9 


Taxes 


8 


Tax: Fed: 
.45 911: 
.08 

Local: 








$0.53 


o 


415 
343- 

QAA1 

764 N 
7159 


06/02/96 


10 


Taxes 


0 




0 






$4.99 


-1 


415 
343- 
8441 

*7CA XT 

7159 


06/02/96 


11 


Instal 
lment 
Billin 
g 


0 


Service 

Connectio 

n 

Residence 
Service 
Flat Rate 


1 


$0.00 


$0.00 


$34.75 


'0 


415 
343- 
8441 
764 N 
7159 


06/02/96 


12 


Instal 
lment 
Billin 
g 


0 


Total - 
Charges 
Applied to 
your 

Installme 
nt Plan 


0 


$0.00 


$0.00 


$34.75 


-1 


415 
343- 
8441 
764 N 
7159 


06/02/96 


13 


Instal 
lment 
Billin 
g 


0 


Your 
Charges 
Will Be 
Billed in 
3 

Installme 
nts 


-1 


$0.00 


$0.00 


$0.00 


0 


415 
343- 
8441 


06/02/96 


14 


Instal 
lment 


9 


Installati 
on 

Payment 


0 


$0.00 


$11.5 
8 


$11.58 


o 
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764 N 
7159 



415 
343- 
8441 
764 N 
7 159 



415 
343- 
8441 
764 N 
7159 



06/02/96 



15 



06/02/96 



16 



415 
343- 
8441 
764 N 
7159 



06/02/96 



415 
343- 
8441 
764 N 
7159 



06/02/96 



415 
343- 
8441 
764 N 
159 



06/02/96 



Instal 
lment 



Total 



17 



18 



19 



Total 



Total 



Total 



Due 1 fo 



10 



11 



Access for 

Intersate 

Calling 

3.50 Per 
Month 



Residence 
Service 
Flat Rate 

11.25 
Per 
Month 



Total for 
415 343- 
1234 



$0.00 



$0.00 



$11,5 
8 



$11.58 



$0.00 



$0.00 



$0.00 



$0.00 



$0.00 



$0.00 



$0.00 



$11.5 



$0.00 



$0.00 



$11.58 



-1 





-^Statement 










415 343-8441 764 N 7 159 


06/02/96 


1 


Amount of last bill 


$0.00 


0 


415 343-8441 764 N 7 159 


06/02/96 


2 


Paymentfs) 


$0.00 


0 


415 343-8441 764 N 7 159 


06/02/96 


3 


Balance 


$0.00 


-1 
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T0000002 Services-v1 





^Statement . 

%t$$l$< ■■ ■■ ■ 


■ 

Group 


/Item 




total 


415 343-8441 
764 N 7 169 


06/02/96 


1 


1 


•We Are Not Holding a 
Deposit on Your Account 


0 


415 343-8441 
764 N 7 159 


06/02/96 


1 


2 


• Service is Billed in Advance 
from the 2nd of Each Month. 


0 


415 343-8441 
764 N 7 159 


06/02/96 


1 


3 


• Easy Access established 
with MCI 

on 1 line(s) effective Jun l t 
1996. 

To verify your carrier, call 1- 
700-555-4141. 


0 


415 343-8441 
764 N 7 159 


06/02/96 


1 


4 


• Activity on 415 343-1234 


-1 


415 343-8441 
764 N 7 159 


06/02/96 


l 


5 


•Order 45417777 


0 


415 343-8441 
764 N 7 159 


06/02/96 


l 


6 


• Installment Billing Effective 
on Jun 1.1996 


0 


415 343-8441 
764 N 7 159 


06/02/96 


2 


7 


• Service Established from 
Jun 1, 1996 thru Jun 1. 1996 


0 



tn 



The Reports 
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a. T0000002-v1 

„.„ 




^*TF..9?^..!?.!!!? UIHt 4 late charge may be applied on ,. T uu. 
[not been received: Your bill, however, must still be paid before the DUE BY 
(ta.a«Qid.QtbflXJtBnaUias.iS9B.Bfix8^fl). 



If your payment has 
date 



Ben - Cualonwr scrvfcK 



jC^ i° f ^.!'°lS^ Servfce - To °PP*y for thfa servfeo cat 
^.ffif^.r.J.?..^ 0 w apP»y *or this service, caft 



^^Hispeno de i Pacific Bel, Home yertis: 



80O-794-97i 



800-794-979' 



Pacific Bell has two services that make it more convenient to pay 
your telephone bill, Automatic Payment Service or Pay-By-Phone. 
With Automatic Payment Serevice your bill is paid automatically 
each month. Pay-By-Phone makes pairing your bill as easy as a 
phone call. Best of all both services are free; For more 
information or to apply for these services call 1-800-794-9794. 



note page separator here ... 
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Pacific Beii Monthly Charges j 81B8Bg^ 

ms^^S^sso^r" - - 






















Additions and Changos to Pacific Boll Sorvicofs) i 






m 


yfltm^jerv^-vl ~L£i™ 








lUUUUUU^lnsti*menl_Billrg-v1 — : . 




TOOQOOO^Savtces-vl — — j 




i::::; ^ 







0 Private Sub Detail_Format (Cancel As Integer, FormatCount As Integer) 

Space (50) _ 

"A late charge may be applied on " _ 
Format (Me! Late_Date, "mmm d") 
lblTotal_Due. Caption _ 

" if your payment has not been received. n _ 
"Your bill, however, must still be paid before " 
" the DUE BY date to avoid other penalties *_ 
* (See Reverse) " 



y3 



lblTotal_Due. Caption s 

a & 

o & 

lblTotal_Due. Caption = 

a 2 

.1 

End Sub 
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Private Sub ReportHeader_Format (Cancel As Integer, FormatCount As 
Integer) 

Dim sAddress (1 To 4) As String 



m 



sAddress(l) = MeJCustomer_Address_l 
sAddress(2) = Me I Customer_Address_2 
sAddress (3) = Me!Customer_Address_3 
sAddress(4) = MelCustomer_Address_4 

If Len {sAddress (1) ) = 0 Then 
sAddress(l) = sAddress(2) 
sAddress (2 ) = s Address (3 ) 
sAddress(3) = sAddress (4) 
sAddress (4) = " ■ 

End If 

If Len (sAddress (2) ) = 0 Then 
sAddress (2) = sAddress (3) 
sAddress (3) = sAddress (4) 
sAddress (4) = 0 ■ 

End If 

If Len (sAddress (3) ) = 0 Then 
sAddress (3) = sAddress (4) 
sAddress (4) = " ■ 

End If 

MeltxtAddress_l = sAddress (1) 
Me ! txtAddress_2 = sAddress (2 ) 
Me!txtAddress_3 = sAddress (3) 
MeitxtAddress_4 = sAddress (4) 



End Sub 



b. T0000002_Current_Charges-v1 



i 




—WWMWSE^ J.J, , 



Note that all of these fields have .Top=0.04 ,, > and that they are spread out for c larity only. 
Pacific BeP Page 2 $27.82 



$27.82 



Private Sub Dot «il_Format (Cancel As Integer, FormatCount As Integer) 

* Line_Bef ore ... 

If Me! Item_Number = 1 Then 

Line_Bef ore. Visible = False 
Description.FontWeight =400 'normal 
lblPage_Number.FontWeight = 400 
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in 

V 

6 

m 

u 
p 

I 
P 



Else 



Amount .FontWeight = 400 



Line_Bef ore. Visible = True 

If MelIs_Total Then 

Line_Be fore. BorderWidth = 3 
Description. FontWeight = 700 'bold 
lblPage_Number. FontWeight =700 
Amount. FontWeight = 700 

Else 

Line_Be fore. BorderWidth = 1 
Description. FontWeight = 400 'normal 
lblPage_Number. FontWeight = 400 
Amount .FontWeight = 400 
End If 
End If 



• lblPage_Number . . . 

If Me I Page_Number = 0 Then 

lblPage_Number. Visible = False 

Else 

lblPage_Number. Visible = True 
lbl Pag e_Number. Caption = "Page 
End If 



& Me l Page_Number 



End Sub 



T0000002Jnstallment_Billing-v1 




Dim miLine_Count 



As Integer 



Private Sub Dot ail_Ponoat (Cancel As Integer, FormatCount As Integer) 

miLine_Count = miLine_Count + 1 

' Line„Bef ore . . . 

If MelIs_Total Then 

Line_Bef ore . BorderWidth = 3 
Description. FontWeight = 700 'bold 
Amount .FontWeight =700 

Else 

Line_Bef ore . BorderWidth = 1 
Description. Font Weight = 400 'normal ' 
Amount .FontWeight =400 
End If 
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'Line_Number . . . 

If Quantity <= 0 Then 

Description. Left = 1 * 1440 
Quantity. Visible = False 

Else 

Description. Left - 1.75 * 1440 
Quantity. visible = True 

End If 



if) 



m 



RJ 

i 



Select Case True 

Case (Quantity = 0 And Len (Description) > 0) Or miLine Count = 1 
Line_Bef ore. Visible = True 
Line_Bef ore. Width =0.5 
Line_Be fore. Left = 1 * 1440 
Line_Be fore. Width = 6 * 1440 

Case Quantity = -l 

Line_Bef ore. Visible = False 

Case Else 

Line__Be fore. Visible = True 

Line_Bef ore. Left = 0 

Line_Bef ore. Width = 5.25 * 1440 

Line_Bef ore . Left - 1.75 * 1440 
End Select 



End Sub 



d. T0000002_Monthly_Charges_Short-v1 




Note that all of these fields have .Top=0.04 w , and that they are spread out for clarity only. 
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Description 


Qty 




Al 


1 . Residence Service Fist Rate 


1 






Monthly Sen/ice Jun 2, 1996 thru Jul 1, 1996 
Description 


Qty Pro-Rated 


One-Time 


Al 


9. Installation Payment Due 1 to 3 




1158 




Description 


Qty Pro-Rated 


1158 
One-Tims 


At 


Service Connection 
Residence Service Rat Rate 


1 






Total Charges Applied to your Installment Plan 


Your Charges Will Be Billed In 3 Installments 
Description 






Al 


2. Charges for Netwrk /ccess for Interstate Calling, Imposed by Federal 
Communications Cim mission 



3. California High Cost Fund Surcharge 



4. Universal Lifeline Telephone Service Surc harge 

5. Rate Surcharge 



6. State Regulatory Fee 



7. C A Relay Service and Comunlcatlons Devices Fund 



8. Tax: Fed .45 911: .08 Local: 



Description 



1 0. Access for Intersate Calling 
3.50 Per Month 



Qty Pro-Rated One-Time 



1 1 . Residence Service Fiat Rate 
• 11 25 Per Month 



Total for 415 343-1234 



11.58 



Dim miLine_Count As Integer 

'**************** ******************************************** 
Private Sub Detail_Foraat (Cancel As Integer, FormatCount As Integer) 

miLine__Count = miLine_Count + 1 

1 Line_Bef ore . . . 

If MelIs_Total Then 

Line_Before.BorderWidth = 3 
Description. Font Weight =7 00 'bold 
Amount .FontWeight = 700 

Else 

Linejef ore . BorderWidth = 1 
Description. FontWeight = 400 'normal 
Amount .FontWeight - 400 
End If 
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• Hne_Number . . . 

If Line_Number = 0 Then 'And Len (Description) > 0 

Description. Left = 0.5 * 1440 
Line_Number. Visible = False 

Else 

Description. Left = 1 * 1440 
Line_Number .Visible = True 

End If 



If (Line_Number = 0 And Len (Description) > 0) Or miLine_Count = 1 

Then 

Line_Bef ore. Width =0.5 
Line„Bef ore. Left = 0.5 * 1440 
Line_Bef ore. Width = 6.5 * 1440 

Else 

Line_Bef ore. Left = 0 
Line_Bef ore. Width = 6.15 * 1440 
Line_Bef ore. Left = 0-85 * 1440 
End If 



'Quantity. . . 

If IsNull (Quantity) Then 

Quantity .Visible = False 

Else 

Quantity .Visible = (Quantity > 0) 
End If 

' lbl Amount_CR . . 

lblAmount_CR . Visible = (Amount < 0) 

End Sub 



Private Sub GroupHeaderO_Format (Cancel As Integer, 

Forma tCount As Integer) 



Select Case Mel Type 
Case "Basic" : 



lblQuantity. Visible = True 
lblPro_Rated. Visible = False 
Pro_Rated. Visible = False 
lblOneJTime. Visible = False 
One_Time. Visible = False 



Case "Taxes": lblQuantity .Visible = False 

lblPro_Rated. Visible = False 
Pro_Rated. Visible = False 
lbl One_Time. Visible = False 
One_Time. Visible = False 



Case Else: 



End Select 



lblQuantity. Visible = True 
lbl Pro_Rated. Visible = True 
Pro_Rated. Visible = True 
lblOne_Time. Visible = True 
One_Time. Visible = True 



miLine_Count = 0 
End Sub 
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e. T0000002_Monthly_Charges_Tall-v1 



IMServlce 



^Description 



* Basic Service 



Description 



JLjSS^^ Amount] 
Qty 



1 . Residence Service Ret Rate 


1 








Monthly Service Jun 2, 1996 ttwu Jul 1, 1936 










Description 


Qty 


Pro-Rated 


Ona-Time 


Ai 


9. Insteilation Payment Due 1 fe 3 






1158 










1158 




Description 


Qty 


Pro-Rated 


One-TiiTE 


Ai 


Service Comectlon 
Residence Service Fid Rate 


1 









Total Charges Applied to your Installment Plan 



Your Charges Wl a Be Blled ri 3 Instedrnents 
* Taxes and Surcharge* 

Description 



2. Charges tor NetvcrkAMes* for Interstate C ding .Imposed by Federal 
Communications Clmmfssion 



3. Cailtomia High Cost Fund Surcharge 



4; UnKerseJ Ufeine Telephone Service Surcharge 



5. Rote Surcharge 



6. State Regulatory F ee 



7. CA Relay Service and Comurtcatlons Devices Fund 



8; Tax: Fed .45 911: .08 Local: 



Dim miLine_Count As integer 

***#★*★★*★+*+****★#************#**#+★#****★*★*****★+ 

Private Sub Detail_Foxmat (Cancel As Integer, FormatCount As Integer) 

miLine_Count = miLine_Count + 1 

' Line_Before . . . 

If Me!Is_Total Then 

Line_Bef6re.BorderWidth = 3 
Description.FontWeight =700 'bold 
Amount .FontWeight = 700 

Else 

Line_Before.BorderWidth = 1 
Description.FontWeight = 400 'normal 
Amount .FontWeight =400 
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End If 



' Line_Number . . . 

If Line_Number = 0 Then 'And- Len (Description) > 0 

Description. Left = 0.5 * 1440 
Li ne_Number .Visible = False 

Else 

Description. Left = 1 * 1440 
Line_Number .Visible = True 

End If 

(fl If (Line_Number = 0 And Len (Description) > 0) Or miLine_Count = 1 

*f% „ . Then 

Line_Bef ore. Width =0.5 
Line_Bef ore. Left = 0.5 * 1440 
O Line__Bef ore. Width = 6.5 * 1440 

. CP Else 

□ Line_Bef ore. Left = 0 

p Line__Bef ore. Width = 6.15 * 1440 

Line_Be fore. Left = 0.85 * 1440 
End If 

W 

yj 'Quantity... 

iff If IsNull (Quantity) Then 

Quantity. Visible - False 

L Else 

L Quantity. Visible = (Quantity > 0) 

~ End If 



.ri ' lblAmount_CR. . 

^ lblAmount_CR . Visible = (Amount < 0) 

End Sub 

Private Sub GroupHeaderO_Format (Cancel As Integer, ForinatCount As 

Integer) 

Select Case Mel Type 

Case "Basic": IblService. Caption = »* Basic Service" 

lblQuantity .Visible = True 
lblPro_Rated. Visible = False 
Pro_Rated. Visible = False 
lblOne_Time. Visible = False 
One_Time. Visible = False 

Case "Taxes": IblService .Caption = •* Taxes and Surcharges" 

lblQuantity. Visible = False 
lblPro_Rated. Visible = False 
Pro_Ra ted. Visible = False 
lblOne_Time. Visible = False 
One_Time. Visible = False 

Case Else: IblService. Caption = " " 

lblQuantity. Visible = True 
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m 
6 



m 



lblPro_Rated. Visible = True 
Pro_Ra ted. Visible = True 
lblOne__Time. Visible = True 
One_Time. Visible = True 

End Select 
miLine_Count = 0 
End Sub 

f. T0000002_Previous_Charges-v1 




I Anount of test bill 


$0.00 I 


| Payment(s) 


$0.00 I 


Balance 


$000 



Private Sub Detail_Format (Cancel As Integer, FormatCount As Integer) 



If Me I IteiruNumber = 1 Then 

Line_Be fore. Visible = False 
Description.FontWeight =400 
Amount . FontWeight = 400 

Else 

Line_Be fore. Visible = True 

If Me!Is_Total Then 

Line__Before.BorderWidth = 3 
Description.FontWeight =700 
Amount. FontWeight = 700 

Else 

Line_Before.E£>rderWidth = 1 
Description.FontWeight = 400 
Amount .FontWeight = 400 
End If 
End If 



normal 



■bold 



' normal 



End Sub 
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T0000002 Services-v1 



m 



m 
□ 

m 




•We fire Not Holding a Deposit on Your Account. 

■Service te Billed In Advance torn the 2nd of Each Month. 

■ Easy Access established wth MCI 
on 1 line(s) effective Jun 1 , 1996. 
To verify your carrier, call 1 -700-55541 41 . 

• Activity on 415 343-1234 

■Order 4541 7777 

"Installment Billing Effective onJun 1 ,1996 

■Service Established from Jun 1 , 1996 thru Jun 1 ,1996 



Private Sub Detail_Format (Cancel As Integer, FormatCount As Integer) 



Select Case Is_Total 

Case True: Deseription.FontWeight = 700 

Case Else: Deseription.FontWeight = 400 

End Select 



'bold 
• normal 



End Sub 
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Appendix G - ESP System Data Flow 
Projections 

An Excel spreadsheet model was developed to quantify estimates of data flow through the 
ESP system. Two scenarios are of particular interest: one corresponding to the pilot 
program scheduled for early 1997 and one corresponding to a mature system. The pilot 
scale results are of immediate interest to enable us to begin ordering the hardware needed 
for development and deployment. The mature system results are of special interest because 
we need to be able to verify that the system architecture is easily scaleable. 

A. Assumptions 

Input data affecting results is shown in Figure 2626 - System Input Volumes and Figure 
2727 - Common Parameters below. Figure 2626 contains assumptions that varied between 

fft QPH wtkilo TTicTlI ro 9797 akAnm B DB .iT««4-: n i . il 





k 

»«fofcSvstem 


1 


Participant Counts 






Statement Originators 


20 


io.ooo" 


Originators. This SSP 
CSPs 


4 


2,500 


Customers 
Customers, This CSP 


2 

2.000 


100 
2.500.000 


Template Data 

Templates Per Originator 


1.000 
1.0 


250.000 
2.0 


Monthly Template Update Size (kb) 
1 Tries per Update Success 
1 Global Template Fraction 


500 
4 


300 
2 


Statement Data 


100% 


40% 


Statements Per Origin ator-Month 


500 


2.000 


Statement Content Size (kb) 


2.5 


10 


Statement Component Counts 






1 Mandatory Generic Enclosures 


1 


1.5 


i Optional Generic Enclosures 


5 


10 


Statement Optional Component Take Rates 






I Personalized Originator Buy-In 


10% 


25%. 


1 Personalized Customer Take Rate 


75% 


40% 


1 Generic Take Rate 


25% 


10% 



Figure 26 - System Input Volumes 
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iPondmon Parameter* • 


Both System* 


statement Component sizes (kb) 




BSP Interactive Page 


40 


Mandatory Personalized ^Access-based) 




Optional Personalized (Access-based) 


60 


Mandatory Generic 


15 


Optional Generic 


60 


Communications Efficiencies 




OrifjtoSSP 


85% 


SSPteSOrifirWS 


98% 


SOrisWStoeSwitch 


90% 


eSwitch toSGen WS 


90% 


SGen WS to CSP 


98% 


CSP to Customer 


85% 



Figure 27 - Common Parameters 



B. Results 

Following are two sets of results, seven pages each set, for the Kansas City Pilot and a 
Mature System. Each set begins with a network diagram summarizing data flow results, 
then a table of input data for the case, and finally five pages of detailed output. The 
calculations are described in the section following. . 
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ePav Syste m Flow Scenann- 

Kansas City P/' W. Revision 2 



OUTPUT 



Statement Side Workstation Monthly Flow* 



■n 



m 
Q 

fti 



Count 

Aggregate Incoming/Share 

From SSPs 

Template Updates 16 
Content Reeds 2,000 

Admin Msgs ' 

Total: 

Aggregate Outgoing 

To eSwitch- 

Template Updates ie 
Content Reeds 2.000 
Admin Msgs 

Total:"" 



Mb 



Lines Required (100% Utilization) 

From SSP: 

Eff: 98% 

To eSwitch: 
Eff: 90% 



Name 


kbits/sec 


mo 


100Mbs 


100,000 


LAN 


T3 


44.184 


70,000 


16Mbs 


16,000 


LAN 


10Mbs 


10.000 


LAN 


T1 


1,544 


2,000 


ISDN 


128 


100 


56K 


58 


150 


28.8 


28.8 


30 


14.4 


14.4 


30 


9.6 


9.6 


30 



8.0 
5.0 



13.0 



8.0 
5.0 



13.0 



1,544 


128 


57.6 


0.0 


0.0 


0.0 


1.544 


128 


57,6 


0.0 


0.0 


0.0 



eSwitch Monthly Flows 



to 

i ^ 

I £fl 



j o 



Aggregate Incoming 

Template Updates 
Content Reeds 
Admin Msgs 


Count 

60 
10,000 


Mb 

40 
25 




Total: 




65 




Aggregate to Storage 

Template Updates 
Content Reeds 
Admin Msgs 


20 
10,000 


10 
25 




Total: 




35 




Aggregate Outgoing 
Template Updates 
Content Reeds 
Admin Msgs 


40 
10,000 


.20 
25 




Total: 




45 




Lines Required (100% Utilization) 

FromSSWS: 1?R 
Eff: 90% 0.0 


57.6 
0.0 


28.8 
0.0 


To SGWS: 

Eff: 90% 


128 
0.0 


57.6 . 
0.0 


28.8 
0.0 



Statement Generation Workstation; Monthly! Flows 



Aggregate Incoming Count Mb 

Template;Updates * 20. HQ. 

ConterttRecds ' 5,000 ■ 13 

Admin Msgs 
From CSP 
Admin Msgs 



Total: 23 



• W PDFs Per 1000 Statements 

! ^ BSP Interactive 1,000 40 

H Acc Req'd, C-Spec 1,000 40 

^ Acc Optional, C-Spe 100 6 

JLJ Req'd, Generic 1 0 

jf Optional, Generic 5 Q 

K Total: 86 

2 Aggregate Outgoing / Share 

^ To CSP 

fZ Initial PDFs 5,000 475 

^ C-Spec Opt PDFs 500 . 20 

!\ Generic Opt PDFs 100 . 9 
Admin Msgs 

y To eSwitch: 

^ Admin Msgs 

^ Total: 504 

yi Lines Required (100% Utilization) 

From eSwitch 
Eff: 90% 

To CSP 

Eff: 98% 



1,544 


128 


57.6 


0.0 


0.0 


0.0 


1.544 


128 


57.6 


0.0 


0.0 


0.0 



CSP Home Banking Software Monthly Flows 



Aggregate Incoming / Share 

Count Mb 

From Stmt Gen WS 

Initial PDFs 5,000 475 

C-Spec Opt PDFs 500 20 

Generic Opt PDFs 100 9* 

Admin Msgs 

_ Total: 504 

$5 Aggregate Outgoing / Share 

To Customers 

H Initial PDFs 5 t 000 475 

g C-Spec Opt PDFs 375 15 

zl Generic Opt PDFs 6,250 375 - 

Sf Admin Msgs 

~ To Stmt Gen WS 

Admin Msgs 



I DO 



Total: 865 
Lines Required (100% Utilization) 





From SGWS 


1,544 


128 


57.6 


j f ( 


Eff: 98% 


0.0 


0.0 


0.0 


! 5 


To Customers 


28.8 


14.4 


9,6 




Net cps 


3,060 


1,530 


1,020 


%0 


Eff: 85% 


0.1 


0.2 


0.3 



Home Banking Software User Monthly Flows 



Statements 5.0 
Incoming PDF Traffic (Expected) 





Per Stmt 


kb 


All Stmts 


kb 


Initial PDFs 


1.0 


95 


5.0 


475 


C-Spec Opt PDFs 


0.1 


5 


0.4 


23 


Generic Opt PDFs 


1.3 


75 


6.3 


375 


Total: 


2.3 


175 


11.6 


873 


nload Times (All Statements) 








Eff: Modem 


57.6 


28.8 


14.4 


9.6 


85% Net cps 


6,120 


3,060 


1,530 


1,020 


Seconds 


143 


285 


570 


855 


Minutes 


2.4 


4.8 


9.5 


14.3 



ePav System Data Flow Model 
INPUT Description 



Mature System, Rev 2 
Variable Name 



Base 



Participant Counts 

Originator Count CntOriginator 1 0,000 

Originator Count, This SSP CntOrigSSP 2,500 

CSP Count CntCSP 100 

Customer Count, Total CntCustTotal 2,500,000 

Customer Count, This CSP CntCustCSP 250,000 
Template Data 

Templates Per Originator TemplPerOrig 2.0 

Monthly Template Update Size (kb) TernplUpdSize 300 

Tries Per Update Success TemplUpdTries 2.0 

Fraction Global Templates TemplGlobaiFrac 40% 
Statement Data 

Statements Per Originator Per Month StmtPerOrigMo 2,000 

Statement Content Size (kb) StmtContentSize 1 0 
PDF Data 
Sizes 

BSP Interactive Size (kb) PDFBSPIntSize 40 

Access Req'd, C-Spec Size (kb) PDFReqdCSpecSize 40 

Access Optional, C-Spec Size (kb) PDFOptCSpecSize 60 

Req'd, Generic Size (kb) PDFReqdGenSize 15 

Optional, Generic Size (kb) PDFOptGenSize 60 
Counts 

Req'd, Generic, Count PDFReqdGenCount 1.5 

Optional, Generic, Count PDFOptGenCourit 10 
Take Rates 

Access Optional, CjSpec Buy-In PDFOptCSpecBuyln 25% 

Access Optional, CXSpec Take Rate PDFOptCSpecTake' 40%r 

Optional, Generic, Take Rate PDFOptGenTake 10% 

Communications Efficiencies 

OrigtoSSP CommEffOrigToSSP 85% 

SSP to SSWS CommEffSSPToSSWS . 98% 

SSWS to eSwitch CommEffSSWSToeSwitch 90% 

eSwitch to SGWS CommEffeSwitchToSGWS 90% 

SGWS to CSP CommEfTSGWSToCSP 98% 

CSP to Customer CommEffCSPToCust 85% 

Constants 

Mb/Mo per k-bits/sec Conv 



ePav System Flow Scenario: 

Mature System. Rev 2 
Statement Side Workstation Monthly Flows 



OUTPUT 



Count 

Aggregate Incoming/Share 

From SSPs 

Template Updates 10,000 
Content Reeds 5,000,000 

Admin Msgs 

Total: 



m 
O 



Aggregate Outgoing 

To eSwitch: 
Template Updates 
Content Reeds. 
Admin Msgs 

Total: 



10,000 
5,000,000 



Lines Required (100% Utilization) 



^0 



Name 


kbits/sec 


$/Mo 


100Mbs 


100,000 


LAN 


T3 


44,184 


70,000 


16Mbs 


16,000 


LAN 


10Mbs 


10,000 


LAN 


T1 


1,544 


2,000 


ISDN 


128 


100 


56K 


58 


150 


28.8 


28.8 


30 


14.4 


14.4 


30 


9.6 


9.6 


30 



Mb 



3,000 
50,000 



53,000 



3,000 
50,000 



53,000. 



From SSP: 


1,544 


128 


57.6 


Eff: 98% 


0.1 


1.3 


2.9 


ToeSwitch: 


1,544 


128 


57.6 


Eff: 90% 


0.1 


1.4 


3.1 



eSwitch Monthly Flows 



m 
v 



m 
p 

fy 
m 



Aggregate Incoming 
Template Updates 
ourueni rcecos 
Admin Msgs 


Count 

40,000. 

on nnn Ann 
20,000,000 


Mb 

12,000 
200,000 




Total: 




212,000 




Aggregate to Storage 
Template Updates 
Content Reeds 
Admin Msgs- 


20,00,0 
20,000,000 


6,000 
200,000 




Total: 




206,000 




Aggregate Outgoing 
Template Updates 
Content Reeds 
Admin Msgs 


812,000 
20,000,000 


243,600 
200,000 




Total: 




443,600 




Lines Required (100% Utilization) 

From SSWS: 1 544 . 
Eff: 90% . 0.5 


128 
5.6 


57.6 
12.4 


To SGWS: 

Eff: 90% 


1,544 
1.0 


128 
11.7 


57.6 
26.0 



Statement Generation Workstation Monthly Flows 



Aggregate Incoming Count Mb 

From eSwitch 

Template Updates 9,200 2,760 

Content Reeds 2,000,000 20,000 
Admin Msgs 
From CSP 

Admin Msgs _^ 

Total: 22,760 

PDFs Per 1000 Statements 

BSP Interactive 1,000 40 

Acc Req'd, C-Spec 1 ,000 40 

Acc Optional, C-Spe 250 15 

Req'd, Generic 2 0 

Optional, Generic 10 1 

Total: 96 



Aggregate Outgoing:/ Share* 
To CSP 

Initial PDFs 2,000,000 205,000 

C-Spec Opt PDFs 500,000 20,000 

Generic Opt PDFs 92,000 10,179 



Admin Msgs 
To eSwitch: 
Admin Msgs 



Total: 235,179 



Lines Required (100% Utilization) 

From eSwitch 1,544 1^8 

Eff: 90% 0.0 0.6 



To CSP 1,544 128 

Eff: 98% 0.5 5.7 



CSP Home Banking Software Monthly Flows 



Aggregate Incoming / Share 







Count 


Mb 






Fmm Stmt f5pn 










Initial PDFc 


9 nnn nnn 


one nnn 






C-Spec Opt PDFs 


500 000 


on nnn 






Generic Opt PDFs 


92,000 


10,179 - 






Admin Msgs 








Total: 




zoo, i /y 




(Ji 


Aggregate Outgoing / Share 










To Customers 










Initial PDFs 


2.000,000 


nnn 




w 


C-Spec Opt PDFs 


200,000 


8,000 




m 


Generic Opt PDFs 


2,000,000 


120,000 




T=ar 


Admin Msgs 








To Stmt Gen WS 










Admin Msgs 










Total: 




333,000 




?? 


Lines Required (100% Utilization) 








From SGWS 


1,544 


128 


57.6 


N= 


Eff: 98%. 


0.5 




12.7 




To Customers 


28.8 


14.4 


9.6 




Net cps 


3,060 


1,530 


1,020 




Eff: 85% 


41.3 


8Z7 


124,0 



Home Banking Software User Monthly Flows 



Statements 8.0 

Incoming PDF Traffic (Expected) 

Per Stmt 

Initial PDFs ™ ^0 

C-Spec Opt PDFs o.1 
Generic Opt PDFs 1.0 
Total:)"" JJ 

Download Times (All Statements) 

Eff: Modem I 57,6 

85% Net cps ' 67T5o" 
Seconds 220 
Minutes 3,7 



kb ! AH Stmts kb 
103 ~ e!o 820 

6 0.8 48 

60 8JD 480 

^69] iel 1^48" 



28.8 14^ 9.6 - 

3,060 1^30 T7o20~ 

441 881 1,322 

73 14.7 2Z0 
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C. Calculation Methods 

This section explains the spreadsheet calculations using the mature case output as an 
example. Each page of output shows data flows incoming and outgoing from a network 
node, and shows the number of communication lines required by type. 

1 . ESP Statement Origination Workstation Monthly Data Flows 

Data flows at the ESP Statement Origination Workstation are due to 
^ Template updates and Statement content. Template updates are expected to 

U consist primarily of changed enclosures and associated distribution logic 

01 Changes to the principal Statement document (e.g. the main invoice) are 

*g expected to be relatively infrequent. 

^ There are 10,000 Template updates per month since there are assumed to be 

£ 2 ' 500 originators served by this SSP, each of which has an average of 2 

^ Templates active 1 , and there are assumed to be 2 attempts required per 

Jf successful registration of a Template update (10,000 = 2,500 * 2 * 2). This 

U corresponds to 3,000 Mb of Template data flow because the size of 

(compressed) Template updates is assumed 2 to average 300 kb. 

^ ^ here are 5.000,000 content records passed through this Workstation 

^ because this SSP is assumed to serve 2,50O originators, each of whom 

m produces an average of 2,000 electronic statements per month (which might 

correspond to a 20 percent ESP share of a 10,000 statement per month 
* biller). Because content records are assumed to be 10 kb each 9 this 

L. corresponds to 50,000 Mb of content data per month 4 . 

p Because the spreadsheet does not model administrative message traffic or 

£} data flow to and from the authoring workstation, incoming and outgoing 

,0 data flow are identical. For estimation purposes, it is unlikely that 

^ administrative message traffic would exceed 10 percent of the total traffic. 

Although it is anticipated that connections between the ESP Statement 
Origination Workstation and the SSP System will be by LAN, calculations 
are shown nevertheless for telecommunications links. A single Tl line 



n! 

m 



1 There is some uncertainty about the average number of Templates Originators may wish to maintain. Simplicity 
suggests they maintain just one. On the other hand, multiple Templates may prove useful for different classes of 
Customers, e.g. residential vs commercial, high-bandwidth vb. low-bandwidth, etc. 

2 This assumption of 300 kb per incremental update corresponds to 5 new enclosures per month, moat of which would 
presumably be optional offers. Currently credit card bill typically include 3 new enclosures per month. These new 
^closures might be selected via demographic logic from a library of 10 enclosures, some of which changed each 
month. Alternately, multimedia features could account for large template updates. 

* The assumption of 10 kb of content data per Statement is quite generous for the average statement. Fixed format 
Stoiemento hke typed [utility bills have less than 500 bytes of Customer-variable content data per Statement. On the 
other hand, telephone bills can contain a large amount of variable data. The ability to provide optional personalized ' 
detail may actually provide incentives for Originators increase Statement content since only those who want it will 
get it. 

4 For purposes of comparison, consider that one of the largest Statement Services Providers (SSPs) now in operation 
received about 2 Gb/hour or about 1,500,000 Mb/month of print stream data. If this Provider were to convert 20 
percent of his present volume to ESP, the resulting operations would be about 6 times larger than the current 
example. 
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operating between 2 and 3 hours per day could transmit the required data 
from the Statement Origination Workstation to the ePay Switch. 
Alternately, two ISDN dial-up lines operating at about 75 percent of 
continuous capacity could accomplish the same transfer. 

2. ePay Switch Monthly Data Flows 

Since the SSP in this case is assumed to service 25 percent of all Statement 
Originators, it follows that the ePay Switch's aggregate incoming flow is 
four times the Statement Origination Workstation outflow. 

New incremental storages at the ePay Switch is approximately the same as 
incoming flow, the only difference being rejected Template updates. Active 
disk-based storage will increase by about 7.5 Gb per month, less deletions. 
Modular high capacity disk storage systems are available that can be 
incremented in 54 Gb blocks. Archival storage of content data via CD-ROM 
will be at the rate of 200 Gb per month, or 40 CDs per day. These CDs will 
be available for screened statistics and for secure investigations by Visa 
personnel. 

Data flowing from the ePay Switch is multiplied by the need to broadcast 
Templates to multiple CSPs. The value of the multiplier depends on the 
weighted coverage fraction of Templates in the entire ESP system, called 
here the Global Template Fraction. This fraction is one if every Template 
is distributed to every CSP; i.e. if all Templates are global. The fraction is 
zero if every Template is used by just one CSP; i.e. if all Templates are local. 
Herein, the global Template fraction is assumed6 to be 40 percent. In the 
present case, it is assumed that 40 percent of the Templates (8,000) are 
global and hence are sent to all 100 CSPs, and that the remaining 60 percent 
are local and sent to just one CSP. Hence 812,000 Templates are sent from 
the ePay Switch (812,0*0 = 0.4 x 20,000 x 100 + 0.6 x 20,000 x 1). The 
upper bound for the number of Template updates sent is 2 million (100 x 
20,000) and the lower bound is just 20,000. This translates into 244 Gb per 
month of Template updates flowing from the ePay Switch, which is 
somewhat more than the 200 Gb of content data flowing through the ePay 
Switch!. 

About 30 ISDN dial-up lines operating at 50 percent capacity would be 
sufficient to handle both incoming and outgoing traffic. High capacity 
factors can be achieved because the ePay Switch will operate in a polling 
mode, calling its workstations in sequence as soon as it can process 
additional data. High volume workstations may profit by using dedicated Tl 
lines. 




Statement Content data is stored at the ePay Switch for research purposes. It is likely that only several days of data 
will be kept on disk, with the remainder being archived to CD-ROM. The bulk of the ePay Switch's storage will be for 
Templates and Template Updates. 

9 Although bounded, this fraction is quite uncertain. Twenty percent may be an underestimate. Nominally local ' 
Statements like those from the Honolulu Water District could be more global than expected. One Sacramento 
resident and one Vancouver resident might own a vacation home in Hawaii and pay their water bills from their 
principal residences, making it necessary for their presumably local CSPs to keep a copy of the Honolulu Water 
District template. 

7 As shown in the equation above, This tendency for Template data to exceed Statement Content data increases with 
the number of CSPs and the Global Template Fraction. 
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3. ESP Statement Generation Workstation Monthly Data Flows 

The CSP in this example is assumed to service 10 percent of all ESP 
Customers. Accordingly it receives one tenth of all content records, 
2,000,000 per month amounting to 20 Gb per month. It also receives 9,200 
Templates: 8,000 "global" Templates and 1,200 local Templates, amounting to 
another 2.7 Gb per month. Total Template storage requirements could reach 
30 Gb, depending on the rate at which Template resources are deleted from 
the system, and on default retirement policies. 

Templates and content records are transformed into Mandatory and 
Optional PDFs at the Statement Generation Workstation. For each 1 000 
Statements, the SGWS produces", on average, 1,000 interactive panel' PDFs 
(e.g., containing buttons to retrieve optional enclosures), 1,000 mandatory 
personalized PDFs, 250 optional personalized PDFs (e.g. invoice detail) 2 
mandatory generic PDFs (e.g., regulatory notices), and 10 optional generic 
PDFs (e.g. promotions). Only 250 optional personalized PDFs are produced 
by the assumption that only 25 percent of Originators take advantage of this 
ESP capability. Generic PDFs are few because of their generic nature. 

The SGWS for this very large CSP is assumed to deliver 2,000,000 
statements per month, and consequently the SGWS shares to the CSPs 
System 2,000,000 initial PDFs, 500,000 optional personalized PDFs, and 
_ 92,000 optional generic PDFs. The first figure is based on one initial PDF 

i B per Customer > a 25 percent sign-up rate on the part of Originators for 

(p optional personalized statements (e.g details), and 10 Optional Enclosures 

J ' P er Temple for 9,200 Templates. The size of the initial PDF is the sum of 

" the interactive PDF, the personalized mandatory PDF, and the expected 

number of generic mandatory enclosures time their average size. In this 
case, the initial PDF averages 102.5 kb (102.5 = 40 + 40 + 1.5 * 15). Thus 
the initial PDFs contribute 205 Gb to the'SGWS outflow. The 500,000 
optional personalized PDF (e.g. statement details) comprise 20 Gb of data. 
The optional enclosure PDFs comprise another 10 Gb of data per month, 
bringing the total outflow to 235 Gb per month. 

Incoming data could be handled by one ISDN line operating at 60 percent 
capacity. Data going out to the CSPs Home Banking System should be via 
network share . 

4. CSP Home Banking System Monthly Data Flows 

Data flows coming to the large CSP Home Banking System modeled herein 
are described above. Aggregate outgoing flows are the initial PDFs 
described previously: 2,000,000 initial PDFs comprising 205 Gb of data, 
200,000 optional personalized PDFs (the assumed 40% of the 500,000 
prepared by the SGWS) actually requested by Customers amounting to 8 Gb 



CO 
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o 



Generic PDPb are not actually produced at the Statement Generation Workstation. Mandatory generic PDFs ai 
appended to the mandatory personalized PDF to form the initial PDF, Optional generic PDFs are simply passed 
along to the CSPs Home Banking Server for delivery on request by individual Customers. 

9 A standard 10 Mbita/aec Ethernet LAN is about 6 times faster than a Tl line. An Token Ring LAN is about 10 
times faster than a Tl line. The still somewhat exotic 100 MBits/sec Ethernet LAN is about 60 times faster. 
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of data, and finally 2,000,000 Optional Generic EnclosureslO requested in 
the aggregate by all customers which account for an additional 120 Gb of 
data* 

^ P ^i me a Bank t ng SyStem data flows are lar S e in *is case, roughly 
5/6 of the : flows through ePay Switch. The problems of the CSPs are 
compounded by the fact that outgoing connections to customers are via slow- 
speed modem (9.6 to 28.8 kbits/sec capable of between 1000 and 3000 
characters per second) and that these connections are Customer-initiated, 
inis latter fact requires considerable equipment redundancy to avoid 
congestion and associated adverse consumer reaction. On a 100 percent 
utilization basis, the number of outgoing 14.4 kbits/sec lines required to 

K e *l Ver ^ 6 D °- f 8 0 Sta ' ement ° 10 250 ' 000 Customers assumed to 
SJEFV? "I 82 " T ° maintain aece Pt«We response during peak 

S^i^SS^ two and five times M ° number of ^ 

5. CSP Customer Monthly Data Flows 

By assumption, the average Customer receives 8 invoices per month 
amounting to 1,350 kb. Using 9.6, 14.4, and 28.8. kbits/sec modems at 85 
percent transmission efficiency, this implies download times of 22, 15 and 7 
minutes for all 8 statements. These estimates do not include a "List of 
Statements screen that CSPS will likely preparers a Table of Contents and 
navigation tool. The average Statement would download completely in less 
than one minute Web-based servers that implemented Adobe's ByteServer 
transmission technology could offer their users considerably more rapid 
response via the interlaced rendering it supports. 

d. Summary of Data Flow Projections 

Sw L fl r. 1 t r nd .u 0m D the Switch durin S P ilot be.about HOrnB per month. Total 
flow to and from fce ePay Switch at maturity will be about 650gB per month. Additional 
flow results are shown below in Figure 3030 and graphically in Figure 2828 and plgTe 

E. Conclusions 

The pilot is of such relatively small scale that data flows are easily managed using 
conventional equipment. Storage requirements are within the capabihtiel of standard 
m^wflT ? omm " mcation8 «wM be accomplished using conventional 28.8 kbits/sec 
^Sni ^ J™" fealiStiC P roducti °n.level equipment and in anticipation of 

rapid system growth, we plan to test more robust equipment and ISDN communications. 

SlffW^r T! d eZP no^ d8 ^ fllr0Ueh ePa > Switch at *y»*»™ maturity, 
the flows throughlarge CS/'ifbmeflonftin^ System* are also very large, so large as to 

suggest the need for architectural improvements prior to commercial release. In particular 

iLZlf*? ^ ""^ "f m *?7 8tatelnent ™<»Wes as possible at the customer's PC. 
Resources that might be cached could be entire PDF documents or document building 
Mocks The more promising approach is to cache the building blocks, such that they could 
be used in multiple documents. The idea would be to send down a PDF framework that 

L ™»™"h ™ T5 eMlOSUr0 ' 8 f Jq,CCt0d *° be re ^ ue9ted 81008 ^ » <™™™* »» •* a 10 percent take rate on 
the assumed 10 available generic enclosures. 
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w!™° r ? Xt f nal «•««*•• not on 'y fl» *e interactive panel (e.g.: bitmaps for blends, 
watermarks, logos, and button faces; sound files for opening and closing events), but also for 
the main document itself. This would entail a fundamental change in the nature of Adobe's 
PDF format, since currently a PDF document is an integral whole with no provision for 
references to external resources. After pilot, we expect to work with Adobe to devise ways to 
reduce data flow between the customer and the home banking System, without 
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TECHNICAL FIELD 
This invention relates to automated banking machines. Specifically this invention 
relates to an automated banking machine apparatus and system that is capable of use in a 
wide area network, and which provides a user with a familiar interface from their home 
5 institution at banking machines operated by other institutions. 

BACKGROUND ART 
Automated banking machines are well known. A common type of automated banking 
machine used by consumers is an automated teller machine ("ATM"). ATMs enable 
customers to carry out banking transactions. Common banking transactions carried out with 

10 ATMs include the dispensing of cash, the making of deposits, the transfer of funds between 
accounts, the payment of bills and account balance inquiries. The type of banking 
transactions a customer can carry out are determined by capabilities of the particular banking 
machine and the programming of the institution operating the machine. 

Currently ATMs are operated in proprietary communications networks. These 

15 networks interconnect ATMs operated by financial institutions and other entities. The 

interconnection of the networks often enables a user to use a banking machine operated by 
another institution if the foreign institution's banking machine is interconnected with the 
network that includes the user's institution. However when the customer operates the foreign 
institution's machine the customer must operate the machine using the customer interface that 

20 has been established by the foreign institution for its banking machines. In addition the user 
is limited to the transaction options provided by the foreign institution. 

1 



A customer may encounter difficulties when using a foreign institution's machine. 
Problems may occur because the user is not familiar with the type of machine operated by 
the foreign institution. Confusion may result because the customer does not know which 
buttons or other mechanisms to actuate to accomplish the desired transactions. The 
5 transaction flow for a customer at a foreign institution machine may be significantly different 
from machines operated by the user's home institution. This may be particularly a problem 
when the user is from another country and is not familiar with the type of banking machine 
or the language of the interface provided by the foreign institution. 

A foreign institution may also provide different types of transactions than the user is 

10 familiar with at their home institution. For example the user's home institution may enable 
the transfer of funds between accounts through their automated banking machines, to enable 
the user to maintain funds in higher interest bearing accounts until they are needed. If the 
foreign institution does not provide this capability, the user will be unable to do this when 
operating the foreign machine. The inability of a user at a foreign machine to conduct the 

15 transactions that they are accustomed to may present problems. 

The networks that operate automated teller machines and other types of automated 
banking machines generally operate proprietary networks to which access is restricted. This 
is necessary to prevent fraud or tampering with the network or user's accounts. Proprietary 
networks are also generally used for the transmission of credit card messages and other 

20 financial transaction messages. Access to such credit card processing systems is also 
restricted primarily for purposes of maintaining security. 
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Communication over wide area networks enables messages to be communicated 
between distant locations. The best known wide area network is the Internet which can be 
used to provide communication between computers throughout the world. The Internet is not 
widely used for financial transaction messages because it is not a secure system. Messages 
5 intended for receipt at a particular computer address may be intercepted at other addresses 
without detection; Because the messages may be intercepted at locations that are distant in 
the world from the intended recipient, the potential for fraud and corruption is great. 

Companies are beginning to provide approaches for more secure transmission of 
messages on the Internet. Encryption techniques are also being applied to Internet messages. 
10 However the openness of the Internet has limited its usefulness for purposes of financial 

messages, particularly financial messages associated with the operation of automated banking 
machines. 

Thus there exists a need for an automated banking machine and system that can be 
used in a wide area network such as the Internet while providing a high level of security. 
15 There further exists a need for an automated banking machine and system which provides a 
user with the familiar interface and transaction options of their home institution when 
operating foreign institution machines. 

DISCLOSURE OF INVENTION 
It is an object of the present invention to provide an automated banking machine at 
20 which a user may conduct transactions. 
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It is a further object of the present invention to provide an automated banking 
machine that may be operated through connection to a wide area network. 

It is a further object of the present invention to provide an automated banking 
machine and system that provides a user with a familiar interface and transaction options of 
5 their home institution at machines operated by foreign institutions. 

It is a further object of the present invention to provide an automated banking 
machine that communicates using HTML documents and TCP/IP messages. 

It is a further object of the present invention to provide an automated banking 
machine that enables the connection of the banking machine to a user's home institution 
10 through HTML documents and TCP/IP messages generated responsive to indicia on a card 
input by a user. 

It is a further object of the present invention to provide an automated banking 

machine and system that accomplishes transactions over a wide area network while 

maintaining a high level of security. 
15 It is a further object of the present invention to provide an automated banking 

machine and system that controls connection of the banking machine to foreign addresses 

through a proxy server. 

It is a further object of the present invention to provide an automated banking 

machine that limits the operation of devices in the machine through a local device server. 
20 It is a further object of the present invention to provide an automated banking 

machine and system that is operable through connection to the Internet. 
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Further objects of the present invention will be made apparent in the following Best 
Modes for Carrying Out Invention and the appended Claims. 

The foregoing objects are accomplished in a preferred embodiment of the invention by 
an automated banking machine that includes an output device such as a display screen, and 
5 an input device such as a touch screen or a keyboard. The banking machine further includes 
devices such as a dispenser mechanism for sheets of currency, a printer mechanism, a card 
reader/writer, a depository mechanism and other physical devices that are used by the 
machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in operative 
10 connection with the output device and the input device, as well as with the sheet dispenser 
mechanism, card reader and other physical devices in the banking machine. The computer 
includes software programs that are executable therein. The software programs include an 
HTML document handling portion. The HTML document handling portion operates to send 
and receive HTML documents. The HTML document handling portion is preferably in 
15 connection with the output device to display screens including hypertext link indicators. The 
HTML document handling portion is also preferably in connection with the input device 
which enables user selection and the generation of response messages from the computer. 
The HTML document handling portion preferably operates in connection with a JAVA 
software environment and has the capability of executing instructions in JAVA script 
20 transmitted with HTML documents. 

The software in the computer further preferably includes a device application portion. 
The device application portion includes software that is operative to control the sheet 
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dispenser and other devices. In the preferred form of the invention the device application 
portion includes a plurality of JAVA applets for operating the devices in the machine. 

The computer in the automated banking machine further includes a device interfacing 
software portion. The device interfacing software portion operates to receive messages from 
the device application portion and to cause the devices to operate through appropriate 
hardware interfaces. In the preferred form of the automated banking machine, the HTML 
document handling portion, device application portion and device interfacing software portion 
each reside on the same computer and communicate at different IP ports. 

The automated banking machine of the invention preferably communicates using 
TCP/IP messages in an intranet which includes a plurality of such machines. The intranet is 
in turn connected to at least one computer which is operated by a home institution. The 
home institution is the entity that operates the banking machines. 

The computer of the home institution preferably includes a home HTTP server, a 
proxy server and a device server. The proxy server communicates through the intranet with 
the HTML document handling portion of the software in each of the banking machines. The 
proxy server is also connectable to a wide area network, such as the Internet, to which 
foreign servers are connected. The device server is operative to pass messages between the 
device application portion and the device interfacing software portion of the banking 
machines. The device server includes monitor software which monitors and selectively limits 
the use and operation of the devices in the banking machine. This provides a level of 
security. 
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The automated banking machine and system is operative to place a user in connection 
with the institution where they have their accounts. This can be either the home institution 
that operates the banking machine where the user is present, or a foreign institution which is^ 
connected to the wide area network. To operate the banking machine a user inputs an 
5 address, such as a URL address, through an address input device. The HTML document 

handling portion operates to connect the banking machine to the server corresponding to that 
address. This is preferably accomplished by the user having indicia representative of the 
address on a card that is read by the banking machine. 

The HTML document handling portion is responsive to the address on the card to 

10 connect through the proxy server to the user's institution. If the user's home institution 
address corresponds to the home server, the banking machine operates responsive to 
messages from the home server. If however the user's input address corresponds to an 
address of a foreign server, the proxy server is operative to communicate ^through the wide 
area network with the foreign server at the customer's home institution. If the customer 

15 causes the machine to connect a server operated by a foreign institution, the HTML 

documents sent from the foreign institution correspond to those normally provided by the 
foreign institution. As a result the customer is familiar with the interface produced by these 
documents and will be able to more readily operate the banking machine. 

The foreign server or home server operate the banking machine by sending HTML 

20 documents that include instructions for operating the devices in the banking machine. The 
instructions are transmitted from the HTML document handling portion to the device 
application portion of the software, which operates the devices in response to the 
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instructions. The instructions from the device application portion to the devices in the 
automated banking machine are passed through the device server of the home institution. 
This helps to maintain security. In addition, the proxy server includes screening software 
which limits the foreign servers which may connect to and operate the banking machine. 
This is referred to as a "fire wall." 

BRIEF DESCRIPTION OF DRAWINGS 

Figure 1 is a schematic view of a network configuration including the automated 
banking machine apparatus and system of the present invention. 

Figure 2 is a schematic view of a preferred embodiment of an automated banking 
machine of the present invention. 

Figures 3 through 24 show schematic views of the automated banking machine, an 
intranet connecting the banking machine to a computer system of a home bank and a wide 
area network connecting the computer system of the home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction carried out at the 
banking machine with the computer system of the home bank. 

Figures 19 through 24 schematically represent steps in a transaction carried out at the 
banking machine with the computer system of the foreign bank. 

BEST MODES FOR CARRYING OUT INVENTION 
Referring now to the drawings and particularly to Figure 1 , there is shown therein a 
network configuration schematically indicated 10, which includes the automated banking 
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machine apparatus and system of a preferred embodiment of the present invention. Network 
10 includes a plurality of automated banking machines 12 which in the preferred embodiment 
of the invention are ATMs. ATMs 12 are connected to a computer system of a home bank 
schematically indicated 14. Home bank computer system 14 is the computer system that is 
5 operated by the bank or other institution which has primary responsibility for the ATMs 12. 
Home bank computer system 14 is connected to the ATMs 12 through an intranet 16. 
Intranet 16 is preferably a local or proprietary network that provides communication between 
the computer system 14 and the banking machines 12 using messages in the transmission 
control protocol/internet protocol ("TCP/IP") format. 

10 The messages that are communicated through the intranet 16 are preferably TCP/IP 

messages and hypertext mark up language ("HTML") documents. In the preferred 
embodiment of the invention the HTML documents sent through intranet 16 include 
embedded object oriented programming instructions, preferably in the JAVA® format which 
has been developed by Sun Microsystems. The messages sent through intranet 16 may be 

15 sent in an encrypted or unencrypted form depending on the nature of the system and the 
security needs of the home bank. 

Home bank computer system 14 is also connectable as shown to a wide area network 
18. In the preferred embodiment of the invention the wide area network 18 is the Internet. 
In other embodiments of the invention, other wide area networks may be used. The wide 

20 area network preferably communicates messages in TCP/IP between numerous computer 
systems connected to the wide area network. These foreign computer systems are 
schematically represented by servers 20, 22, 24, 26 and 28. It should be understood that 
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servers 20 through 28 may be operated by or connected to other financial institutions 
throughout the world. Servers 20 through 28 preferably operate by communicating HTML 
documents. 

Figure 2 shows a schematic view of the ATM 12 used in connection with a preferred 
embodiment of the invention. ATM 12 includes a touch screen 30. Touch screen 30 
includes a display screen which serves as an output device for communication with a user of 
the machine. Touch screen 30, because it is a touch screen, also serves as an input device 
for receiving input instructions from a user. Touch screen 30 is connected through an 
interface 32 to a computer 34 which is preferably housed within the machine. 

Computer 34 is also in connection with a plurality of devices 36 which are included in 
ATM 12. Devices 36 include for example, a card reader/writer mechanism 38 and a 
keyboard 40. Devices 36 further include a sheet dispenser mechanism 42 which is operative 
to dispense sheets, which in the preferred form of the invention are currency or bank notes. 
Devices 36 also include a depository 44 for accepting deposits into a secure location in the 
machine. A receipt printer 46 for providing transaction receipts to customers is also included 
among devices 36. A journal printer 48 is also included among the devices for keeping a 
hard copy record of transaction information. 

Each of the devices is connected to an internal control bus 50 within the banking 
machine 12. The control bus 50 outputs the internal messages to the particular devices. 
Each device has an appropriate hardware interface which enables the particular device to 
operate in response to the messages transmitted to it on control bus 50. Card reader/ writer 
38 has a hardware interface schematically shown as 52. Hardware interfaces 54, 56, 58, 60 
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and 62 are respectively operative to connect keyboard 40, sheet dispenser mechanism 42, 
depository mechanism 44, receipt printer mechanism 46 and journal printer mechanism 48 to 
the control bus 50. 

Computer 34 has several software programs that are executable therein. In the 
preferred embodiment of the invention these software programs include a device interfacing 
software portion generally indicated 64. Device interfacing software portion 64 preferably 
includes a software device interface 66 that communicates electronic messages with the 
control bus 50. The device interface software portion 64 also preferably includes a device 
manager 68. The device manager is preferably operative to manage the various devices 36 
and to control their various states so as to be assured that they properly operate in sequence. 
The device manager is also preferably operable to create device objects in the software so as 
to enable operation of the devices by the object oriented program 70. Device interfacing 
software portion 64 also includes the object oriented program portion 70, which in the 
preferred embodiment is an application written in the JAVA language. Program 70 works in 
conjunction with the device manager to receive object oriented JAVA messages which cause 
the devices to operate, and to transmit device operation messages indicative of a manner in 
which devices are operating and/or are receiving input data. 

The device interfacing software portion 64 in the preferred embodiment operates on 
computer 34 and communicates through a physical TCP/IP connection 72 with the intranet 
16. The physical connection may be analog dial-up, serial port, ISDN connection or other 
suitable connection. In the configuration of the system as shown, device interfacing software 
portion 64 communicates at the IP address of computer 34 and at an IP port or socket 
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indicated 74 that is different from the other software applications. In other embodiments of 
the invention, device interfacing software portion 64 may operate in a different computer 
than the other software applications of the invention. 

It should further be understood that although in the preferred embodiment of the 
5 invention the device interfacing portion 64 is software, in other embodiments of the invention 
all or portions of the instruction steps executed by software portion 64 may be resident in 
firmware or in other program media in connection with one or more computers, which are 
operative to communicate with devices 36. 

Other software also operates in computer 34. This software includes HTML 

10 document handling software which includes a browser, schematically indicated 76. In the 
preferred embodiment of the invention the HTML document handling software includes a 
browser provided by Netscape®. However in other embodiments other HTML document 
handling and communicating software and browser software, such as Hot JAVA® by Sun 
Microsystems, may be used. Browser 76 communicates in computer 34 at an IP port 

15 indicated by 78. 

Browser 76 is in operative connection with JAVA environment software 80 which 
enables computer 34 to run JAVA language programs. JAVA language programs have the 
advantage that they operate the same on a variety of hardware platforms without 
modification. This "write once\run anywhere" capability makes the JAVA environment well- 

20 suited for the preferred embodiment of the invention. However other embodiments may use 
different types of software programs. 
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The JAVA environment software 80 enables computer 34 to execute instructions in 
JAVA script, schematically indicated 82. The instructions that are executed by the computer 
in JAVA script are preferably embedded JAVA script commands that are included in the 
HTML documents which are received through the browser 76. The browser 76 in 
5 connection with the JAVA environment software 80 which executes instructions in the 
embedded JAVA script 82, serve as an HTML document handling software portion for 
transmitting and receiving HTML documents and TCP/IP messages through the IP port 
indicated by 78. 

Computer 34 also has executable software therein having a device application portion 
10 84. The device application portion 84 contains executable instructions related to operation of 
the devices 36. In the preferred embodiment of the invention, the device applications portion 
consists of a plurality of JAVA applets. The applets are also preferably operable to control 
and keep track of the status of the devices with which they are associated. Certain applets 
are also preferably operable to configure the browser to communicate messages. Certain 
15 applets manage security and authenticate entities that use the ATM. 

In the preferred form of the invention, JAVA applets are associated with enabling the 
card reader mechanism, notifying the browser when a user's card data has been entered, 
operating the receipt printer mechanism, operating the journal printer mechanism, enabling 
the customer keyboard and receiving data input through the keyboard, operating the sheet 
20 dispenser mechanism, verifying digital signatures, handling encryption of messages, 

controlling the mix of bills dispensed from multiple sheet dispenser mechanisms, calculating 
foreign exchange, and ending a transaction and instructing the browser to return to 
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communication with the home server. Of course, in other embodiments, other applets may 
be used to carry out various desired functions or to control devices in the machine. The 
device application portion 84 communicates in the computer 34 at an IP port indicated by 86. 

In the preferred embodiment of the invention, the device application portion 84 of the 
software does not communicate its messages directly to the device interfacing software 
portion 64. As later explained, this provides heightened security. However it should be 
understood that embodiments of the invention may provide for the device application portion 
84 to directly communicate device operation messages to the device program 70. This may 
be done either internally using TCP/IP, by delivery of messages in a conventional manner 
through a queue established in the operating system of the computer that is associated with 
the software that interfaces with the devices, or by direct call to this software. 

From the foregoing discussion it will also be appreciated that certain applets in the 
device application portion 84 may correspond to devices which are not present in all 
automated teller machines. For example an automated teller machine that operates only as a 
cash dispenser does not include a depository mechanism like depository 44. To 
accommodate the situation where a user requests a transaction that is not physically possible 
with the ATM 12, the device interfacing software portion 64 may be programmed to provide 
an appropriate response message to indicate that the function is not available. 

Alternatively, the device interfacing software portion may include a function which 
checks for the presence or absence of each type of physical device within the ATM. 
Information indicative of the devices present in the ATM may be included as part of the 
messages generated by the ATM. For example, information indicative of the devices which 
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are operative in the ATM may be included as part of the URL addresses to which messages 
are directed by the ATM. In this way, the URL in the server to which the ATM connects 
may be configured for providing only HTML documents which correspond to the types of 
transactions that the ATM is capable of performing. 

Figure 3 shows the ATM 12 in communication through the intranet 16 with the home 
bank computer system 14. Computer system 14 includes a proxy server 88. System 14 
further includes a home HTTP server 90. Computer system 14 further includes a device 
. server 92. The proxy server, home HTTP server and device server may be included in a 
single computer as shown, or in other embodiments may be separate computers. 

The home HTTP server 90 is preferably in electronic communication with a back 
office computer system, schematically indicated 94. Back office computer system 94 is 
operative to keep track of debiting or crediting customers' accounts when they conduct 
transactions at the automated banking machines. In addition back office 94 is also preferably 
operative to track transactions for purposes of accomplishing settlements with other 
institutions who are participants in the system and whose customers conduct transactions at 
the ATMs 12. 

As later explained, proxy server 88 is also operative to communicate through the wide 
area network 18 with foreign servers such as foreign server 96. Foreign server 96 is an 
example of a server operated by an institution other than the institution which operates 
computer system 14. It should be understood that while foreign server 96 is indicated as 
operated by a "foreign" institution, this is not necessarily indicative that the institution is 
located in another country from the institution that operates computer system 14. However, 
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it is possible that foreign server 96 could be located in such a foreign country, including a 
country in which the language spoken is different from that generally used in the country 
where ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with reference to 
Figures 3-24. It should be understood that the following described transaction flows are 
merely examples of the operation of the apparatus and system, and the apparatus and system 
may be configured and operated in numerous ways to carry out transactions. 

At the start of an exemplary transaction, as schematically represented in Figure 3 , the 
browser 76 communicates through the intranet 16 with the proxy server 88. The 
communication is established preferably in a manner so that HTML documents intended to 
attract customers to the ATM 12 are displayed on the touch screen 30. This is referred to as 
the "attract mode." These HTML documents which produce the screens on the touch screen 
30 originate from home HTTP server 90 which is operative to deliver the HTML documents 
to the proxy server. The home HTTP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display at the proper ATM machine. It 
should be understood that while in this example, home server 90 is described as 
communicating with the ATMs through the proxy server 88, the server 90 may in other 
systems encompassed by the invention communicate directly with the ATMs. 

A fundamental advantage of the system is that home HTTP server 90 may deliver 
documents selectively to the ATMs 12 connected to the intranet 16. These documents may 
include messages tailored to the particular location in which an ATM 12 is located. 
Examples of particularly tailored screens may include bilingual messages in certain 
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neighborhoods or information concerning currency exchange at various ports of entry. The 
JAVA applets and JAVA script are loaded from a central location providing selective 
software distribution in the ATMs which may also be used to tailor the ATM to its 
environment. 

The touch screen 30 in this exemplary transaction displays a screen which includes an 
icon which indicates in one or more languages that to commence a transaction a user should 
touch the screen. If a user touches the screen in the area of the icon an input signal is 
generated. The input signal is transmitted through the browser 76 to the home address of the 
home HTTP server 90 to which the ATM 12 is currently in communication. The message 
generated back to the home HTTP server is represented by the arrows directed from the 
browser 76 to the intranet 16, from the intranet 16 to the proxy server 88, and from the 
proxy server to the HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message indicating that a 
customer has touched the icon on the screen, the home server is operative to send a message 
through the proxy server 88 (or in other embodiments directly) to the browser 76. This 
message preferably is an HTML document which produces a screen instructing the customer 
to insert their card into the card reader mechanism 38. The HTML document flow which is 
represented graphically in Figure 4, preferably also includes embedded JAVA script 
instructions which operate in the JAVA environment to communicate a message to the JAVA 
applet responsible for enabling the card reader in the device application portion 84. 

As shown in Figure 5, in response to the embedded JAVA script activating the JAVA 
applet associated with the enable card reader function, the JAVA applet in the device 
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application portion 84 communicates with the device server 92. The device server 92 
includes a device server program 98 which in the preferred embodiment is a JAVA program 
that enables communication with the JAVA applets and the device server application 100. 
The device server 92 further preferably includes a monitor software application 102 which is 
operative to monitor device operation instructions. The monitor software minimizes the risk 
of fraud or abuse in a manner later explained. 

Returning to the sample transaction, in response to receiving the enable card reader 
message from the device application portion 84, the device server 92 is operative to generate 
a message through the intranet 16 to the device interfacing software portion 64 of the ATM 
12. This message is directed to the IP port indicated 74 which is where the device 
interfacing software portion 64 communicates. In response to receiving this message, the 
software portion 64 is operative to send a message on the control bus 50 which enables card 
reader mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the card by the 
customer to the card reader 34 is operative to cause the card data to be read and the device 
interfacing program portion 64 to send a message to the device server 92 indicating the card 
data has been read. This message is transmitted by the device server through the intranet 16 
to the device application portion 84. The device application portion then sends a message to 
the device server requesting the card data. The device server 92 transmits a message 
requesting the card data from the device interfacing software portion 64 which responds by 
sending the card data through the intranet to the device server. The device server, if there is 
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no basis for stopping the transaction, transmits the card data back through the intranet 16 to 
the device application portion 84. 

In the preferred embodiment of the invention, the card input by a user or customer 
includes indicia which corresponds to an address associated with the user in the network. In 
the preferred embodiment the indicia corresponds to a uniform resource locator ("URL") 
address which provides information on the computer where the user information resides, as 
well as a directory or subdirectory which includes the user information and the name of the 
. resource that includes the user information. The URL address may be encoded on a 
customer's card. The address may be encoded on track 3 of a magnetic stripe, in other 
locations within the magnetic stripe data or through encoding other readable indicia on the 
card. Alternatively, if the customer's card is a "smart" card which includes semiconductor 
storage thereon, the URL address associated with the customer may be included as part of 
the stored data on the integrated circuit chip on the customer's card. Alternatively, a URL 
could be derived from other data on the card by accessing a data base in which address data 
is correlated with other data read from the card. 

Returning to the exemplary transaction, the delivery of the card data from a 
successfully read card is delivered responsive to the programming of the device application 
portion 84 to a JAVA applet associated with notifying that the card data has been entered. In 
response, the JAVA applet operates to generate JAVA script which configures the browser 
with the URL address from the card. The JAVA applet is also preferably operative to open 
a record schematically indicated 104 concerning the transaction, which includes the user's 
URL address, the time and other card data. 
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As schematically shown in Figure 7, in response to the browser 76 receiving the URL 
address data, the browser is operative to transmit a message through the intranet 16 to the 
proxy server 88. For purposes of this example, the URL address associated with the card 
data is that of a customer associated with the home bank which operates system 14. As a 
result, the customer's URL address will cause the message to be directed from the proxy 
server 88 to the home HTTP server 90. Alternatively, in other systems the connection may 
be made directly with server 90 without the intervening proxy server 88. As previously 
discussed, the URL address may also include data representative of the devices which are 
operative in the ATM. 

In response to receiving the message, home HTTP server 90 finds the data 
corresponding to the customer's URL address data in memory and responds back to the web 
browser at its IP port with an HTML document. This HTML document may include a 
screen acknowledging the particular customer by name as well as with the name of the 
banking institution or other entity which operates the home bank computer system 14. 

In addition, the HTML document preferably includes embedded JAVA script which 
has a digital signature or a means to obtain a digital signature associated with the home 
HTTP server 90. This digital signature is received from the JAVA script 82 and processed 
in a JAVA applet in the device application portion 84. The JAVA applet for processing the 
digital signature authenticates it and authorizes operation of the banking machine. 
Alternatively or in addition the applet may check the signature against a listing of digital 
signatures for servers which are authorized to operate the banking machine. After the applet 
verifies that server 90 has sent a proper digital signature, the transaction will be allowed to 
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continue. If for some reason a proper digital signature has not been sent, the JAVA applet 
will stop the transaction and return banking machine 12 back to the condition prior to the 
start of the transaction by connecting the ATM to the address associated with the attract 
mode in home server 90. 

In the example it will be assumed that the digital signature sent by home server 90 is 
a proper signature, in which case a message is returned from the browser 76 to home server 
90 indicating that the transaction may proceed. As shown in Figure 8, in this exemplary 
transaction the HTTP home server 90 then operates to send an HTML document to the 
browser 76 which includes a page or screen which instructs the customer to enter their 
personal identification number or PIN. This HTML document preferably includes embedded 
JAVA instructions to have the device application portion 84 enable the keyboard 40 of the 
ATM so the machine may receive the PIN number. Such a message is schematically shown 
in Figure 8 with the JAVA script 82 signalling the JAVA applet responsible for the keyboard 
that it has been requested to enable the keyboard. In response the JAVA applet in the device 
application portion 84 sends a message through the intranet 16 to the device server 92. The 
device server 92 sends a message back through the intranet to the device interfacing software 
portion 64 in the ATM. This message causes the device software to enable keyboard 40. 
The JAVA applet responsible for enabling the keyboard is also preferably operative to update 
the transaction record 104 to indicate that the PIN was requested. 

As shown in Figure 9, the PIN entered through the keyboard 40 is transmitted from 
the device interfacing software portion 64 to the device server 92. The device server 92 
returns a message to the responsible JAVA applet in the device application portion. The 
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JAVA applet then operates to cause the JAVA script to send a message back through the 
HTML document handling portion and the browser 76 to the HTTP home server 90. This 
message includes data representative of the PIN input by the customer. 

The HTTP server 90 is then operative to either verify the PIN itself or to verify the 
customer's PIN number and account number by sending it to the back office 94 and waiting 
for a response. Alternatively, customer PIN verification may be carried out in the ATM 
through an appropriate applet. This can be done in situations where data on a customer's 
card, such as an account number, can be correlated to the customer's PIN number through an 
algorithm. The embedded JAVA script in the HTML messages may include the data which 
the applet uses to perform this verification function, including certain encryption key data. 
As shown schematically in Figure 9, the transaction record 104 is also appropriately updated 
by the applet to indicate the entry of the customer's PIN. 

It should be noted that the page or screen which requests the customer to enter their 
PIN is generated from the home HTTP server 90. This is preferably a screen that is 
associated with the particular customer's URL address. This will be the interface of the 
customer's home bank and will be familiar to the customer. Alternatively, the customer 
address may access what may be essentially the customer's personal "home page" with the 
institution that operates computer system 14. As such, it is not only something the user is 
familiar with, but is ideally tailored to the user's particular transaction needs. 

The continuation transaction flow for this exemplary transaction by a customer of the 
institution that operates computer network 14, is schematically shown in Figure 10. The 
home HTTP server 90 is operative in response to the customer inputting the correct PIN to 
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send HTML documents to the HTML document handling portion of the software in the 
computer which operates the ATM. These messages may include screens which prompt the 
customer to select a transaction. For purposes of this example, it will be assumed that the 
customer inputs at the touch screen 30 a selection which corresponds to the dispense of cash, 
which is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch screen is 
communicated back through the HTML document handling portion which communicates a 
message to the home HTTP server 90. Server 90 then responds by sending another HTML 
document to the banking machine which prompts the customer to select an amount. Again 
the customer may input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This input message again passes through the HTML document 
handling portion and the browser 76 back to the home server 90. 

In response to the receipt of amount data from the customer, the home server 90 is 
preferably operative to communicate electronically with the back office 94 to verify that the 
customer has the amount requested in their account. This is preferably accomplished through 
a Common Gateway Interface (CGI) 106 which is in operative connection with the home- 
server 90. For purposes of this transaction it will be assumed that the back office 94 
indicates that the money is available in the customer's account and sends a message through 
the CGI 106 to the home server 90 indicating that it may proceed. 

As schematically represented in Figure 11, the home server 90 then operates to send a 
document back to the HTML document handling portion in the ATM software. This 
message preferably will cause information to be displayed on the screen which advises the 
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customer that the transaction is being processed. In addition the HTML document preferably 
includes JAVA script with embedded instructions which are executed and communicated to a 
JAVA applet associated with the operation of the sheet dispensing mechanism 42. 

The message to the JAVA applet in the device application portion 84 of the software 
results in generation of a TCP/IP message to the device server 92. The message to the 
device server 92 to dispense cash is preferably analyzed by the monitor software 102 to 
check to see if the message is appropriate. Specifically the monitor software 102 is 
preferably operative to assure that the amount of cash being requested does not exceed a 
preset amount. It can also optionally check to verify that the amount provided to this 
customer within a prior period has not exceeded an amount. This may be done by the device 
server sending a message to the back office which includes the card data it has previously 
received from this customer. This message may pass through server 90 and its associated 
CGI, or other connection. Assuming that the dispense instruction is not prevented by a 
message from the back office or the monitor software, the device server 92 is operative to 
send a dispense message to the device interfacing software portion 64 in the ATM. The 
software portion 64 is thereafter operative to operate the sheet dispensing mechanism 42 to 
dispense the amount of cash requested by the customer. 

The monitor software 102 preferably performs additional functions in the device 
server. For example, government regulations or good business practice may require limiting 
the size and amounts of deposits which may be made into an ATM. This may be advisable 
to prevent "money laundering" or other suspicious activities. The monitor software 
preferably operates to limit the amount of any single deposit to below a set limit. It further 
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operates by communicating with the home bank back office system 94 to prevent a series of 
deposits within a preset time from exceeding a certain limit. The monitor software may also 
work in connection with the proxy server to limit certain transactions that may be carried on 
at the banking machine responsive to instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the JAVA applet 
which is operative to send the message which causes cash to be dispensed, works in 
connection with another applet which controls the mix of bills dispensed to a customer. 
. Many automated teller machines have the ability to dispense two or more denominations of 
currency bills. It is desirable to control the mix of bills dispensed to a customer to suit that 
which is available in the machine and to avoid running out of one denomination of bills 
before the other. The bill mix applet is preferably operable to control the bill mix in 
accordance with the desires of the institution operating the ATM machine as well as is in 
accordance with the ATM machine's capabilities. Alternatively, a JAVA applet for 
controlling bill mix may reside in device program 70 in device interfacing software portion 
64. 

As will be appreciated by those skilled in the art, the particular JAVA applets in the 
machine may be selectively loaded from the home server 90 at machine start up. Because 
the applets may be selectively delivered to particular machines, they may be tailored 
specifically to the particular ATMs currency dispensing capabilities. 

In response to the cash dispenser 42 dispensing the requested amount of cash, device 
interfacing software program 64 preferably operates to send a dispense operation message 
confirming the dispense back to the JAVA applet responsible for the dispense in the device 
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application program 84. As represented in Figure 12, the particular applet is operative to 
update the transaction record 104 to indicate the dispense of currency to the customer in the 
particular amount. The embedded JAVA script instructions which were operative to cause 
the dispense of currency to the customer, also preferably include instructions to send a 
confirming message back to the home server 90 that the dispense is complete. The receipt of 
the dispense operation message indicating the cash was dispensed causes the JAVA applet to 
configure the HTML document handling portion to send a device response message back to 
the home server. The home server then is preferably operated in accordance with its 
programming to indicate to the back office 94 that the customer received the amount of funds 
dispensed. This amount is deducted from the customer's account in the records maintained 
by the back office system. 

Generally during a transaction it is common to ask the customer if they wish to have 
a receipt for the transaction. This may be done at various times during the transaction flow. 
In the present example, after the cash has been dispensed the customer operating the machine 
is sent such a message as reflected in Figure 13. The home server 90 is operative to send an 
HTML document which includes a screen asking the customer if they would like a receipt. 
This message is displayed as part of a page on the touch screen 30 responsive to receipt of 
the message through the browser 76. In response to the customer indicating that they do or 
do not want a receipt, a message is returned to the home server. Again it should be 
understood that the screens displayed to the customer are those that the customer is 
accustomed to from his or her home institution, and may be a part of his or her unique home 
page. 
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Assuming that the customer wishes to receive a transaction receipt, the home server 
90 operates as shown in Figure 14 to send a document back to the ATM with embedded 
JAVA script indicating that a transaction receipt is to be printed. These instructions in 
JAVA script are communicated to the device application portion 84 which sends a TCP/IP 
message through the intranet to the device server 92. The device server 92 in turn 
communicates with the device interfacing software portion 64 in the ATM. In response to 
receiving the message, software portion 64 is operative to cause the printer 46 to print the 
customer's transaction receipt. The JAVA applet responsible for enabling the printer is also 
preferably operative to update the transaction record 104. 

It should be understood that even if the customer does not wish to have a receipt it is 
desirable to print a record of the transaction in hard copy through the journal printer 48. 
This may be accomplished in response to imbedded instructions which are part of the same 
document from the home server 90 which causes the transaction receipt for the customer to 
be printed, or may be part of a separate document which indicates that the customer has 
declined the option to receive a transaction receipt. Alternatively, the journal printer may be 
actuated responsive to other applets such as the applet which causes the dispense of cash, or 
in another manner chosen by the operator of the ATM. As will be appreciated from the 
foregoing description the operation of the preferred embodiment of the ATM is inherently 
flexible and programmable to meet the needs of the system operator. 

As shown in Figure 15 upon completion of the printing of the transaction receipt, the 
software portion 64 is preferably operative to send a device operation message to the device 
server 92 which is indicative that the requested device function was carried out successfully. 
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The device server 92 is operative to send a corresponding device operation message to the 
device application portion 84, and in the preferred embodiment to the particular JAVA applet 
responsible for the printing of the receipt. The JAVA applet in turn configures the HTML 
document handling portion to generate a message back to the home server in the form of a 
5 device response message to indicate that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by an HTML 
document from the home server 90 to indicate whether they wish to conduct another 
transaction. A page or screen prompting the customer in this regard is displayed at the touch 
screen 30. For purposes of this example it will be assumed that the customer does not want 

10 another transaction and a message to that effect is returned through the HTML document 
handling portion back to the home server 90. 

As shown schematically in Figure 17 in response to receiving a message that the 
customer is done, the home server 90 is operative to send a "go home" message to the ATM. 
This message preferably includes an HTML document thanking the customer, as well as 

15 embedded JAVA script which calls the JAVA applet which eventually returns the HTML 
document handling portion of the ATM back into connection with the URL address on the 
home server 90 which carries on the messages for the so called "attract mode". 

As schematically indicated in Figure 18, the "go home" command applet is operative 
to configure the browser 76. After the HTML document handling portion is configured by 

20 the JAVA applet to return home, the JAVA applet may be configured to deliver to home 
server 90 information from the transaction record 104 concerning the transaction that was 
just completed. Because the exemplary transaction was with a customer of the institution that 
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operates the computer system 14, all the data concerning that transaction should already be 
recorded in the back office 94. However it will be appreciated that this will not be the case 
if the transaction was conducted in response to messages from a server operated by a 
different institution. Thus, the information from the transaction record 104 may be delivered 
in response to a "go home" command to the home server 90 and through the CGI to the back 
office system 94 where it can be identified as duplicate information and discarded. 

Of course in other embodiments transaction information may be stored in a database 
for extended periods rather than being returned after each transaction. Alternatively the 
ATM 12 of the present invention may include applets which are operable to deliver 
transaction record information to addresses other than that of the home server, if that is 
desired by the operator of system 14. 

The operation of the computer system when a "foreign" user uses the ATM 12 is 
graphically represented with regard to Figures 19 through 24. A transaction with a foreign 
user who is not a customer of the institution that operates ATM 12 and computer system 14, 
will be operated under the control of the home server 90 and will proceed in the manner of 
the prior example through the point where the customer inputs their card. The customer 
inputs a card having indicia corresponding to a URL address that does not correspond to the 
home server 90. The HTML document handling portion is operative to configure a message 
addressed to a URL address that corresponds to the indicia on the customer's card. This 
message is delivered to the proxy server 88 which in turn passes the message to the wide 
area network 18. From the wide area network the message proceeds to the foreign server 
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corresponding to the customer's URL address. For purposes of this example the foreign 
server corresponds to server 96 which is connected to the Internet. 

In the preferred embodiment of the invention proxy server 88 includes screening 
software graphically indicated 107. Screening software is preferably operable to check 
addresses to which messages are being directed by the ATM and to selectively prevent the 
sending of messages to particular addresses. This serves as a "fire wall" and is desirable for 
purposes of preventing fraud in the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to communicate 
documents to the ATM 12 back through the wide area network 18. This is preferably done 
using a secure socket connection ("SSC") so as to minimize the risk of interception of the 
messages. Of course other techniques, including encryption message techniques may be used 
to minimize the risk of interception of the messages. 

As schematically represented in Figure 20 the response document from foreign server 
96 preferably includes embedded JAVA script representative of a digital signature which 
corresponds to and identifies the foreign server 96. An applet device in application portion 
84 in the ATM preferably operates to authorize the digital signature in the manner described 
in the prior example, and sends a message indicating that the transaction has been authorized. 
The digital identity of the foreign institution will be stored in the ATM and eventually 
recorded in the back office 94. 

It should be noted that the HTML documents from the foreign server 96 produce the 
pages or screens of the foreign institution which the foreign customer is accustomed to 
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seeing. Preferably these pages correspond to the foreign user's "home page" which are 
tailored specifically to the needs of the particular user. 

Figure 21 shows an example of a document coming from the foreign server 96 to the 
ATM 12. The document from the foreign server may include embedded JAVA script which 
enables operation of the JAVA applets in the manner previously discussed to operate the 
devices 36 in the ATM. As shown in Figure 21 the TCP/IP messages to the devices from 
the JAVA applets pass from the device application portion 84 to the device server 92, and to 
the device interfacing software portion 64 in the ATM. Device operation messages take a 
reverse path. As these messages pass through the device server 92, monitor software 102 
monitors them to minimize the risk of fraud or abuse. 

As indicated in Figure 21, the documents from the foreign server 96 may be operative 
to display at the touch screen 30 a request for the customer to input their PIN. The 
embedded JAVA script instructions would, as in the sample transaction previously discussed, 
include instructions that enable the keyboard 40 to accept the customer's PIN. As in the 
prior example, a transaction record 104 concerning this transaction would be opened by the 
device application software portion. 

Figure 22 indicates the return of the device operation message and PIN data to the 
JAVA applet which in turn transmits the data back to the foreign server 96 through the wide 
area network 18 using the secure socket connection. From this point the transaction proceeds 
generally as previously described, except that the foreign server 96 sends the HTML 
documents and receives the TCP/IP messages from the HTML document handling portion of 
the ATM. The foreign server 96 includes the JAVA application software necessary to 
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include the embedded JAVA script in the documents that are sent to the ATM to operate the 
devices 36 in the machine. As the foreign server 96 operates the machine however, the 
monitor software 102 in the device server 92 is operative to monitor the messages in the 
manner previously discussed. Such monitoring would for example, operate to prevent the 
dispense of unduly large amounts of currency out of the machine. 

As can also be appreciated from the foregoing disclosure, the foreign server 96 may 
communicate to the user through the touch screen in a language that is different from that 
normally used by the customers of the institution that operates the computer system 14. As a 
result the HTML documents may display requests to dispense currency of a type or in an 
amount which is not included in the ATM. To accommodate this situation an applet is 
included in the device application portion 84 to deal with requests for foreign currency. The 
foreign currency applet causes the ATM to send a message back to its home server for 
purposes of calculating a closest amount which may be provided to the customer in the 
available currency in the ATM which corresponds to what the customer requested. As will 
be appreciated, this applet will be operative to call the particular function address within the 
home server 90 that is capable of providing this function. When the dispense is made the 
applet is also operative to indicate to server 96 that the amount dispensed differs somewhat 
from the amount the customer requested. Of course in other embodiments, other approaches 
may be used. 

As represented in Figure 23, when the foreign customer has completed their 
transactions as indicated through the touch screen 30, the foreign server 96 is operative to 
send the "go home" message back to the ATM. The receipt of this message is operative in 
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the manner previously described to cause the device application portion 84 to operate 
responsive to the embedded JAVA script instructions to configure the HTML document 
handling portion to cause the browser 76 to reestablish communication with the home server 
90. 

5 As indicated in Figure 24 the applet in the device application portion 84 which 

processes the "go home" message is preferably operative to reconnect to the home server 90 
as well as to send the transaction record information in record 104. This transaction record 
information which includes the customer name, the foreign institution name, digital 
identifier, amount information and all other pertinent transaction data is communicated to 

10 server 90 through the CGI 106 to the home bank's back office 94. This information is 
stored in the back office for later use for purposes of settlement with the foreign bank 
operating the foreign server 96. 

It will be appreciated that the preferred embodiment of the automated banking 
machine and system of the present invention provides the advantage that when the machine is 

15 connected to a wide area network such as the Internet, customers are able to carry out their 
banking transactions virtually anywhere in the world. Further, despite the broad capabilities 
of the system, because the machine is monitored locally, both in terms of connection and 
activity, the risk of fraud is minimized. 

While the preferred embodiment of the automated banking machine and system of the 

20 present invention is shown with regard to a particular type of machine that is made 
specifically for connectibility to wide area networks, conventional automated banking 
machines may also be adapted to include such capability. Specifically the HTML document 
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handling portion and device application portions may be included with other conventional 
software which operates within an automated banking machine. This enables such ATMs to 
operate either in the conventional proprietary network or as part of a wide area network. In 
addition, automated banking machines may be configured to operate their devices through the 
device interfacing software portion of the invention or through a different software interface 
when operating in a conventional network. Such machines may switch to requiring device 
messages to be passed through a device server when operating under the control of a server 
within the wide area network to maintain security within the system. In this way a single 
ATM could operate in proprietary networks in the manner of current ATMs as well as in the 
network configuration of the system of the invention. 

Alternative embodiments of the invention operate to communicate transaction 
messages used in a proprietary ATM network. This may be accomplished by using a CGI in 
connection with either the HTML document handling portion of the ATM or the HTTP home 
server. The CGI operates in connection with a message conversion program to cull the 
necessary data from the HTML documents and TCP/IP messages and generates the 
transaction request messages appropriate for the proprietary transaction network. Likewise, 
the message conversion program and CGI operate to receive function command messages 
from the proprietary network and convert them to appropriate HTML documents and/or 
TCP/IP messages for use by the ATM. Because these proprietary network formats are 
defined and the data necessary to produce and interpret the messages are known, the use of 
the ATM 12 directly in a conventional proprietary ATM network is achieved. 
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The ability of ATM 12 to communicate in a proprietary network also enables 
operation of the ATM in a manner in which the interface is generated by a user's home 
institution in the manner previously described, but in which transactions are authorized 
through messages directed through a proprietary ATM network. This achieves the security 
5 of using the proprietary network while providing the customer with the advantages of the 
familiar home bank interface and/or "personal home page" interface. 

A further advantage of the system configuration of the preferred embodiment is that it 
has enhanced flexibility for communicating messages associated with the ATM. The device 
manager 68 preferably generates status messages associated with the status of devices 36. 

10 These status messages may commonly represent information about conditions which exist at 
the devices. Such messages may indicate that supplies of paper for printers or currency, are 
low or are depleted. Other messages may indicate that devices are not functioning properly. 
Often such messages indicate that the ATM requires servicing. 

The device interfacing software portion 64 communicates through the intranet 16 

15 using TCP/IP messages. While the messages associated with transactions previously 

described are directed to the device server 92, the software portion 64 may be configured to 
address fault messages to other addresses in the intranet. For example, such fault messages 
may be directed to a software application which delivers messages to a service provider. 
Further, fault messages may be selectively directed based on the nature of the fault indicated. 

20 For example, fault messages indicative of a need to replenish currency or supplies may be 
directed to an address in the intranet associated with an entity who has responsibility for 
replenishing supplies. Alternatively, fault messages which indicate a need for other types of 
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servicing may be directed to an address associated with an entity who can provide the type of 
servicing required. 

Alternatively, the selective dispatching of fault messages to addresses in the intranet 
16 may be accomplished by appropriately configuring device server 92. In addition, either 
software portion 64 or device server 92 may direct fault messages from the ATMs to a fault 
handling system such as to a computer operating Event Management System™ software 
available from Diebold, Incorporated. Such software is operative to resolve the nature of the 
. fault condition and to notify appropriate personnel of the corrective action to be taken. 

Thus the new automated banking machine and system of the present invention 
achieves the above stated objectives, eliminates difficulties encountered in the use of prior 
devices and systems, solves problems and attains the desirable results described herein. 

In the foregoing description certain terms have been used for brevity, clarity and 
understanding. However no unnecessary limitations are to be implied therefrom because 
such terms are for descriptive purposes and are intended to be broadly construed. Moreover 
the descriptions and illustrations herein are by way of examples and the invention is not 
limited to the details shown and described. 

In the following claims any feature described as a means for performing a function 
shall be construed as encompassing any means capable of performing the recited function and 
shall not be deemed limited to the particular means shown in the foregoing description or 
mere equivalents thereof. 

Having described the features, discoveries and principles of the invention, the manner 
in which it is constructed and operated and the advantages and useful results attained; the 
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new and useful structures, devices, elements, arrangements, parts, combinations, systems, 
equipment, operations, methods, processes and relationships are set forth in the appended 
claims. 



37 



CLAIMS 



We claim: 

1 . Apparatus comprising : 

a banking machine, including: 

5 an output device, wherein such output device outputs information to a 

user; 

an input device, wherein a user is enabled to input messages to said 
machine; 

a sheet dispenser mechanism; 

10 a computer, wherein said computer is in operative connection with the 

output device, the input device and the sheet dispenser mechanism; 

software executable in said computer, said software including: 

an HTML document handling portion in operative 
connection with the input device and the output device, 
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wherein said HTML document handling portion is 
operative to receive HTML format documents; 

a device application portion in operative interfacing 
relation with the HTML document handling portion, 
wherein said device application portion is in operative 
connection with the sheet dispenser, and wherein said 
device application portion is operative responsive to the 
HTML document handling portion receiving an HTML 
format document including a dispense instruction to 
cause the sheet dispenser mechanism to dispense at least 
one sheet. 

2. The apparatus according to claim 1 and further comprising a card reader mechanism 
in operative connection with the HTML document handling portion of the software, and 
wherein the card reader is operative to accept a card, wherein said card includes indicia 
thereon, and wherein said indicia corresponds with a system address associated with the user, 
and wherein said HTML document handling portion is operative to cause a message to be 
generated to the system address responsive to said card indicia. 

3. The apparatus according to claim 2 wherein the system address for the user includes a 
URL address. 
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4. The apparatus according to claim 1 wherein in said banking machine said HTML 
document handling portion and said device application portion both communicate messages 
through TCP/IP, and wherein said HTML document handling portion communicates at a first 
IP port and said device application portion communicates at a second IP port. 

5 5. The apparatus according to claim 4 wherein the software in the banking machine 

further comprises a device interfacing software portion, and wherein said device interfacing 
software portion is operative to interface with said sheet dispenser mechanism, wherein said 
application portion interfaces with said sheet dispenser mechanism through said device 
interfacing software portion, and wherein said device interfacing software portion 
10 communicates at a third IP port. 

6. The apparatus according to claim 1 wherein said HTML document handling portion 
includes a browser. 

7. The apparatus according to claim 1 wherein said dispense instruction is an embedded 
instruction. 

15 8. The apparatus according to claim 1 wherein said dispense instruction is in JAVA 
script. 
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9. The apparatus according to claim 1 wherein said device application portion includes a 
first applet, wherein said first applet is operative to cause operation of said sheet dispenser 
mechanism. 

10. The apparatus according to claim 1 wherein said banking machine further comprises a 
printer mechanism, wherein said printer mechanism is in operative connection with said 
computer, and wherein said printer mechanism is operative responsive to the device 

. application portion of the software, and wherein said printer mechanism is operative to print 
responsive to receipt of a print instruction by said HTML document handling portion. 

11. The apparatus according to claim 1 wherein said banking machine further comprises 
at least one device, said device being one of a printer mechanism, a card reader mechanism 
or a depository mechanism, and wherein said device is operative responsive to the device 
application portion of the software, and wherein the device is operative responsive to receipt 
of a device instruction by the HTML document handling portion. 

12. The apparatus according to claim 1 wherein said dispenser mechanism is operative 
responsive to dispensing said sheets to cause a dispenser operation message to be delivered to 
the device application portion of the software, and wherein said HTML document handling 
portion is operative responsive to delivery of the dispenser operation message to output a 
dispense response message from said HTML document handling portion. 
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13. The apparatus according to claim 11 wherein the device is operative responsive to its 
operation to cause a device operation message to be delivered to the device application 
portion of the software, and wherein the HTML document handling portion is operative 
responsive to the delivery of the device operation message to output a device response 
message from the HTML document handling portion. 

14. The apparatus according to claim 12 wherein the HTML document including the 
dispense instruction includes a response instruction, wherein said response instruction is 
operative to cause the output of the dispense response message responsive to delivery of the 
dispense operation message to the device application portion of the software. 

15. The apparatus according to claim 1 and wherein said banking machine further 
comprises a plurality of devices, said devices operative responsive to the device application 
portion of the software, and wherein said device application portion includes at least one 
applet operative to control at least one of said plurality of devices. 

16. The apparatus according to claim 15 and wherein said software further comprises a 
device interfacing software portion operative to interface with said devices, and wherein said 
device interfacing software portion includes a device program operative to interface with said 
one applet. 
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17. The apparatus according to claim 16 wherein said applet is operative to communicate 
through a second IP port and the device program is operative to communicate through a third 
IP port. 

18. The apparatus according to claim 1 and further comprising a home HTTP server in 

5 operative connection with the HTML document handling portion of the banking machine, and 
wherein the home HTTP server is operative to send HTML documents to the HTML 
document handling portion of the software in the banking machine. 

19. The apparatus according to claim 18 wherein the home HTTP server is operative to 
send the dispense instruction to the banking machine. 

10 20. The apparatus according to claim 18 wherein the home HTTP server includes a home 
address, and wherein the HTML document handling portion of the software is operative to 
send a message to the home address in response to a user input at said input device. 

21. The apparatus according to claim 18 wherein said home HTTP server has a home 
address, and wherein said banking machine further comprises a card reader mechanism in 
15 operative connection with said device application portion of the software, whereby said card 
reader mechanism is operative to read card indicia on a card input by a user, and wherein 
said HTML document handling portion is operative to send a message to the home HTTP 
server responsive to the card indicia corresponding to the home address. 
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22. The apparatus according to claim 21 wherein said card indicia further corresponds to 
identifying information associated with a file, wherein said file is associated with the user, 
and wherein said file is stored in operative connection with the home HTTP server. 

23. The apparatus according to claim 22 wherein said card indicia includes a URL 
5 address associated with the user. 

24. The apparatus according to claim 22 wherein the file includes at least one HTML 
document associated with the user. 

25. The apparatus according to claim 18 and further comprising a proxy server in 
operative connection with the home HTTP server, wherein the home HTTP server has a 

10 home address, and said HTML document handling portion has a machine address, and 

wherein said proxy server is operative to direct messages from said banking machine to the 
home HTTP server responsive to said messages including the home address. 

26. The apparatus according to claim 25 wherein the proxy server is also in operative 
connection with a wide area network, and wherein said wide area network includes a foreign 

15 server, wherein said foreign server has a foreign address, and wherein said banking machine 
further includes an address input device in operative connection with the HTML document 
handling portion, and wherein the HTML document handling portion is operative responsive 
to input of the foreign address through said address input device to generate a foreign 
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message addressed to the foreign address, and wherein said proxy server is operative 
responsive to receipt of the foreign address to pass the foreign message to said wide area 
network 

27. The apparatus according to claim 26 wherein said proxy server includes screening 
software, wherein said screening software is operative to prevent the sending of the foreign 
message to at least one selected foreign address. 

28. The apparatus according to claim 26 wherein said proxy server is operative responsive 
to receiving a foreign response message from said foreign address directed to said machine 
address to pass the message to said HTML document handling portion of the software in said 
banking machine. 

29. The apparatus according to claim 5 and further comprising a device server, wherein 
said device application portion of said software and said device interfacing software portion 
communicate through said device server. 

30. The apparatus according to claim 29 wherein said device server includes monitor 
software, wherein said monitor software is operative to limit operation of said sheet 
dispensing mechanism. 
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ABSTRACT 

An automated banking machine (12) is operative to conduct transactions in response 
to HTML documents and TCP/IP messages exchanged with a local computer system (14) 
through an intranet (16), as well as in response to messages exchanged with foreign servers 
(20, 22, 24, 26, 28, 96) in a wide area network (18). The banking machine includes a 
computer (34) having an HTML document handling portion (76, 80, 82). The HTML 
document handling portion is operative to communicate through a proxy server (88), with a 
home HTTP server (90) in the intranet or the foreign servers in the wide area network. The 
computer further includes a device application portion (84) which interfaces with the HTML 
document handling portion and dispatches messages to operate devices (36) in the automated 
banking machine. The devices include a sheet dispenser mechanism (42) which dispenses 
currency. The device application portion communicates with a device interfacing software 
portion (64) in the banking machine through a device server (92) in the intranet. The device 
server maintains local control over the devices in the banking machine including the sheet 
dispenser. The banking machine operates to read indicia on the user's card corresponding to 
a system address. The computer is operative to connect the banking machine to the home or 
foreign server corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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